This allows power-cycling the robot remotely without using the dashboard
server.

…ng program (#287)

Before, the dashboard client was printing a warning when no program was
running and the `commandRunning` call was made. However, not having a
program running is an absolutely valid result of that command, so it
should not produce a warning about an unexpected answer.

The test seems to be flaky with 1s timeout. As we use 10 seconds at
other places, as well I guess it wouldn't hurt to use this in the tests.

…gram (#292)

Add functionalities to stop the running program and to unlock a
protective stop through the primary client.

There were some headers missing, which lead to build problems on some platforms.

In #266, we improved the behavior of the urcl regarding reconnection
attempts and timeouts for sockets. However, there are still a few
problems (more to come later). I propose to fix one of them here to keep
the scope of the PRs small.

`RTDEClient::setupCommunication` is called in a while loop, and inside
`RTDEClient::setupCommunication` there is a call to
`pipeline_->init(...)` which in turn calls
`producer_.setupProducer(...)`. `setupProducer` (see
[here](https://github.com/UniversalRobots/Universal_Robots_Client_Library/blob/62d34dff101bc460a4d36692405fd076974b8791/include/ur_client_library/comm/producer.h#L67))
throws if the connection of the `stream_` (which is just a tcp socket in
my understanding) fails. Hence, if the RTDE sockets are not available,
this causes the initialization sequence to terminate immediately and not
retry for the desired `max_initialization_attempts`.

Now that I have a deeper understanding of the URCL after digging deeper
a bit (sorry that I didn't bring that up earlier), I don't fully agree
with the `rtde_initialization_attempts` and
`rtde_initialization_timeout` anymore since the RTDE sockets are just
usual tcp sockets that are already subject to
`socket_reconnect_attempts` and `socket_reconnection_timeout`. This
means that currently it's just a while loop of connecting tcp sockets in
a while loop for the RTDE connection setup which is maybe not really
necessary and just creates a lot of delays. But it's also possible that
I miss an important detail about RTDE comm so maybe my feeling is wrong
here.

As we now have more capabilities in the primary interface, we don't need
to rely on the dashboard client to initialize the robot in the example
robot wrapper.

This adds support for starting a PolyScopeX-based URsim. The default
version will still be the latest PolyScope 5 version.

At this moment, this does not install the External Control URCapX as we
don't have a download of the built package available.

---------

Co-authored-by: Mads Holm Peters <79145214+urmahp@users.noreply.github.com>