Re-implement position direct mode

Relates to https://github.com/roboticslab-uc3m/yarp-devices/issues/198, check that issue for a full rationale.

This PR re-implements yarp::dev::IPositionDirect mode on the iPOS drives. Low-level CAN bus communications have been refactored in the following manner:

Both PT and PVT submodes are available and configurable via YARP config option and the IRemoteVariables interface. Default is PT.
Likewise, it is now possible to set a custom period ("T") for all PT/PVT targets. Same default as usual: 50 milliseconds.
In the third place, users can now also configure the most convenient buffer size. This buffer used to hold seven points, now it's one and two points for PT and PVT submodes, respectively, on a default configuration.
Both involved periods have been decoupled: the one that governs the setPosition() send rate from clients to CAN master (YARP comms), and the other that manages the rate at which the PT/PVT buffer is filled up (CAN comms). It is expected that the former is at least equal or more frequent than the latter.
PT/PVT sequences undergo downsampling with regard to the actual points sent through YARP in such a manner that these operations could be thought of as governed by a LIFO stack: only most recent points will be loaded into the buffer at a fixed rate, whereas remaining points which arrived in the meantime are always discarded.
PVT submode requires an additional location in the buffer so that boundary velocities can be computed for successive points.
The TechnosoftIpos device is responsible for actual mode change, loading initial points into the buffer, constructing and sending the messages, as well as sending the start PT/PVT command. Some of these have been refactored into a LinearInterpolationBuffer class and PtBuffer+PvtBuffer subclasses, and two new methods in the ITechnosoftIpos interface: sendLinearInterpolationTarget() and sendLinearInterpolationStart().
The CanBusControlboard device manages send operations in a new periodic thread which is started in suspended state on device open. This thread is resumed whenever one or more joints enter position direct mode, and suspended again if none is controlled in this manner. The goal of the thread is to synchronize point send operations across all joints.
It was decided to keep the buffer non-empty at all times, that is, if no point was received from the user, the aforementioned thread keeps sending the same last point over and over again This point is stored in the LinearInterpolationBuffer class tree.
examplePositionDirect has learned to parse CLI options via YARP's ResourceFinder goodies.
Even though yarp::dev::IRemoteVariables has been preserved (it was meant to serve a different purpose in earlier iterations of this patchset) in spite of some serious pitfalls described at https://github.com/roboticslab-uc3m/yarp-devices/issues/198#issuecomment-495322968 (and also https://github.com/roboticslab-uc3m/yarp-devices/issues/211#issuecomment-494928896 regarding joint ids), it's only intended for use via RPC for ease of access to low-level configuration (see first three bullets on this list).
It is important to note that PVT submode will command quick stop in case the buffer depletes and the last point sent did not have zero velocity. Since buffer depletion is meant to never occur, such circumstance is believed to happen because of both small buffer sizes and tiny interpolation periods. PVT has been successfully used to command a TEO's arm via joystick with circa 20 ms periods, though, and about 4-6 points in the buffer if I recall correctly.
Future work: determine the best instant at which the PT/PVT start message should be sent with regard to the rate at which the periodic thread operates (currently no delay): https://github.com/roboticslab-uc3m/yarp-devices/blob/a70f4466803190aa73212e8befa4c8aa1a6efad1/libraries/YarpPlugins/CanBusControlboard/PositionDirectThread.cpp#L28-L30

roboticslab-uc3m / yarp-devices

Re-implement position direct mode #220