Migrate to ros2dds bridge

[luca-della-vedova]

Closes #17.

This seems to work but required a fair bit of changes in the nexus_network_configuration package, so we should probably rethink what that package does and how.

Specifically, it had a builtin support for generating configs from redf, but it actually didn't and just used hardcoded endpoints here.
Furthermore, while with the dds plugin we can just specify endpoints as strings, the ros2dds plugin requires us to clearly say whether each substring is a publisher, subscriber, service server, service client, action server or action client.
The way I approached it in this PR is the same as the previous PR, updating the config file accordingly, however there are a few important changes to consider

Redf compatibility

redf does not have a way to specify for each topic / service etc. which nodes can publish and which can subscribe, so the only way to include redf config in its current implementation would be to allow each entity to be both, which breaks the isolation a bit since (for example), we currently do:

# System orchestrator
    allow:
      service_servers: [[...] "/register_workcell"]

# Workcell
    allow:
      service_clients: ["/register_workcell"]

Allowing both would mean technically allowing a rogue workcell to advertise a /register_workcell client which could create a lot of trouble in the system.
Note however that this is also an issue in the current implementation.

Because there was no usage of redf for network configuration I couldn't test it and whether it worked or not before I'm fairly sure it will stop working with this PR.

Queries timeout

The ros2dds bridge adds a concept of timeout for a query. They can be pretty granular but the main issue is that they also apply to actions so if an action was to take longer than the specified value it would fail.
I set it to 10 minutes as a default, but this should probably be double checked (increased? made more granular?).

Namespaces

Sadly, while the ros2dds bridge supports namespaces, they currently also apply them to global topics. This means that if we set a bridge with namespace workcell_1 and asked it to allow a subscription to /chatter it would silently only allow /workcell_1/chatter. This makes it pretty painful because workcells need to access global services to register, so we can't rely on namespaces and have to add them manually to each workcell configuration.

Warning spam

Last but not least, running the ros2dds bridge results in a lot of warnings being printed, they seem to be harmless but are still very noisy. An upstream issue has been opened and acknowledged by Zettascale.