Updated the list of RTDE data packages for consistency with
https://www.universal-robots.com/articles/ur/interface-communication/real-time-data-exchange-rtde-guide/.

Also added tests for all possible RTDE fields matching their software versions.

This seems to be a problem otherwise when compiling with clang++

Couple of improvements related to TCP communication:

1. the error handling in `tcp_server::readData` seems wrong since the
error case should be when the number of bytes received is strictly
negative and not equal to 0
2. added early disconnection in `tcp_socket::read` in case of permanent
failure in order to ease failure detection
3. added robustness to `UrDriver::sendScript`: the program sending is
now retried once after closing and reconnecting the secondary stream.
This is the workaround described in
UniversalRobots/Universal_Robots_ROS_Driver#459.
It helps mitigate program sending issues when working with the UR ROS2
driver in headless mode.

New tests added for 2 and 3. For 1 the debug output of
`TCPServerTest::client_connections` seems to confirm the behaviour makes
sense. We now see `client from FD <xx> sent a connection reset package`
which is what I'd expect given the client willingly terminates
connection.

With some control modes such as the trajectory passthrough controller it
is actually possible to run the communication at much lower frequencies.

However, so far we always initialize the `RTDEClient` with the maximum
frequency that is possible on the respective model.

This adds a function to `UrDriver` to reset the `RTDEClient` with
another communication frequency.

## ToDo

- [x] Implementation
- [x] Write tests
- [x] Write documentation

Adding

```
-n for container name
-p for IP address
-f for port forwarding
```

This way, multiple instances of URSim Docker can be started on one host.

…#208)

Co-authored-by: Felix Exner <feex@universal-robots.com>

The example runs seem to fail quite often. This PR aims at fixing that.

It seems that the simulated robot is reporting readiness for executing programs
a bit too early and if we execute the program rightaway it is not started correctly.
This only seems to happen in CI though.

Not all RTDE outputs are available in all SW versions. When working with
a fleet of robots with heterogeneous SW versions it's not practical to
have multiple RTDE output recipes to account for this.
This PR aims at solving this problem by adapting the RTDE output recipe
on-the-fly based on the robot response to the RTDE request. Outputs
which are not available for this particular SW version are simply
removed from the output recipe and a trimmed down output recipe is sent
to the robot.

Potential issues / improvements:
- variables removed from the output recipe only cause a warning. When
these variables are "optional" this is a fine behaviour but it could
potentially be masking incorrect variable names. Hence, this is an opt-in feature.
- an alternate implementation could be to hardcode the compatibility
information for RTDE outputs in `data_package.cpp` and validate the
output recipe beforehand. This seems less flexible though.
- the same logic could potentially be applied to the input recipe.
Having optional inputs seems less likely though.