Improve primary interface

[fmauch]

This branch will

• Add a full primary client object structure to the client
• Read more data from the primary interface
• Give users output when script code sent to the primary interface gets started and finishes as requested in Forward script execution failures back to the user #163, Script command by action API #118, URScript execution status #19, Remote URScript execution best practice #40 which will hopefully help with Publishing script commands doesn't yeild anything #131 Sending URScript commands for gripper have no effect  #77
• Show users when they send malformed script code to the robot
• Inform users when they are trying to send script code to an e-Series robot which is not in remote control mode
• Output any error messages coming up on the robot

I am not sure yet, to which extent all of those things will be tackled in this MR, but it will definitely be a start from which such features could easily be implemented.

[gavanderhoorn]

High-level comment: one of the pain points with ur_driver and ur_modern_driver was the reliance on parsing the binary protocol used on tcp://:30002 et al. This was a pain point, as the binary protocol changes/changed between updates.

The approach employed here in ur_robot_driver was to use RTDE to avoid doing this and thus not have to play catch-up to changes in the protocol as with RTDE the consumer is in control of which fields are part of the messages.

This PR seems to introduce more binary parsing: have measures been put in place to avoid problems with these parsers if/when updates are released, or are the packets parsed expected to "never" be updated?

[fmauch]

High-level comment: one of the pain points with ur_driver and ur_modern_driver was the reliance on parsing the binary protocol used on tcp://:30002 et al. This was a pain point, as the binary protocol changes/changed between updates.

Yes, I am very well aware of that, but unfortunately there are features only available in those interfaces. And at least some of them will not be moved to other interface, as for example the controller is only sending script execution feedback on the particular socket connection that has sent the script. The benefit from getting this feature currently outperforms those concerns from my point of view, as many users seem to struggle with sending script code.

The approach employed here in ur_robot_driver was to use RTDE to avoid doing this and thus not have to play catch-up to changes in the protocol as with RTDE the consumer is in control of which fields are part of the messages.

This PR seems to introduce more binary parsing: have measures been put in place to avoid problems with these parsers if/when updates are released, or are the packets parsed expected to "never" be updated?

This is currently only a draft implementation and no, there's no such thing currently. But it is definitely on the feature list. I plan to do a similar approach as done in the ur_modern_driver. In combination with integrated testing at UR (which we currently try to push) we hope to keep the pain at developer's side, at least :-)

[fmauch]

Closing in favor of UniversalRobots/Universal_Robots_Client_Library#26