Major CAN rework

[PeterBowman]

This PR tracks several [CAN-TEO] issues, detailed as follows:

• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/209: CAN read/write operations now all belong to CanBusControlboard and reside in their own, separate threads. Raw subdevices access incoming messages via callback (as usual) and register outgoing messages to a sender delegate. CAN devices forced to non-blocking mode.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/20: merged oneCanBusOneWrapper, launchManipulation and launchLocomotion into launchCanBus, now allowing to bind an arbitrary number of CAN master devices to another arbitrary number of YARP wrappers given a conveniently parsed configuration file.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/227: the serial Dextra controlboard device has been refactored and a new CAN-enabled device is available.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/159: SDO reads/writes now await their corresponding response/acknowledge with timeout, no more hardcoded arbitrary delays.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/153: refactored hardcoded constants into a new pulsesPerSample Technosoft device configuration parameter.
• Addresses https://github.com/roboticslab-uc3m/yarp-devices/issues/223: added abstraction layers around CANopen protocols (currently SDO, PDO, EMCY, NMT and CiA402 state machine).
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/207: YARP's config monitor handle is now correctly passed to raw subdevices (due to YARP's buggy behavior).
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/74: CanBusControlboard::open needed some love; now, most stuff was moved to the respective subdevice initialization methods or other, more convenient places.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/215: implemented CiA 402 drive state machine with mappings to YARP control modes (includes a cleaner homing procedure).
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/211: CanBusControlboard's subdevices have been deprived from unused YARP interface implementations; CuiAbsolute is now wrapped by the TechnosoftIpos device and regarded as an external encoder.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/171: CanBusControlboard has learned to properly map exposed motor joints to controlled raw subdevice axes.
• Addresses https://github.com/roboticslab-uc3m/yarp-devices/issues/232: leverage CANopen-related stuff (doc-type issue).
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/217: switched to polling mode on CuiAbsolute so that encoder reads are only requested on device initialization and used for synchronizing the relative encoders with them, using these values as an offset to the subsequent relative encoder reads during the whole execution of the program.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/157: implemented yarp::dev::IMotor, yarp::dev::IMotorEncoders and yarp::dev::IAxisInfo in TechnosoftIpos.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/230: parallelize CAN transfers.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/237: parse INI file according to the new layout.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/226: allow one CanBusControlboard instance to manage two or more CAN buses.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/234: remove CAN-related stuff in TextilesHand, promote to a controlboard device.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/241: review fake CAN devices, parse/hardcode in controlboard master device.
• Closes https://github.com/roboticslab-uc3m/yarp-devices/issues/120: manage stop command with controlword's halt bit instead of a transition to "Quick stop active" state.
• Addresses https://github.com/roboticslab-uc3m/yarp-devices/issues/170: fix consecutive control mode change.

TODOs:

• [x] Parse .ini groups of parameters common to all CAN and wrapper devices.
• [x] Re-enable ICanBusSharer client apps (examples, tests...).
• [x] Pass CAN data size along with data pointer in SDO semaphore await and notify actions?
• [x] 6060h vs 6061h on SDO await.
• [x] Add C++11-related CMake flags.
• [x] Check whether data part in SDO messages is guaranteed to fit exactly 8 bytes.
• [x] Hide private implementation of CANopen stack library.
• [x] Harmonize CANopen class names.
• [x] Write doxy documentation.
• [x] Prepare unit tests.
• [x] Ensure thread safety where needed.
• [x] Use std::atomic in new StateVariables class.
• [x] Move TPDO callbacks somewhere else (TechnosoftIpos.cpp? use std::bind?).
• [x] Move error register-related code into its own callback(s)?
• [x] Refactor control mode-related stuff into CanBusSharerLib?
• [x] Parse remaining statusword bits, e.g. motor on/off?
• [x] Call DriveStatusMachine methods instead of CanOpen::rpdo1?
• [x] Add log levels to StateVariables::reportBitToggle (YARP logger?)
• [x] Fix compiler warnings reported in Travis.
• [x] Embrace C++11's move semantics and perfect forwarding.
• [x] Pass lambda parameters by value?
• [x] Pimpl & rule-of-three.
• [x] Review homing procedure (checkMotionDone failures).
• [x] Easily disable absolute encoders?
• [x] Resurrect PT/PVT modes.
• [x] Try yarpmotorgui.

[PeterBowman]

Useful info regarding move semantics (includes perfec#- - t forwarding):

• https://www.internalpointers.com/post/c-rvalue-references-and-move-semantics-beginners
• https://blog.petrzemek.net/2016/08/17/auto-type-deduction-in-range-based-for-loops/
• https://stackoverflow.com/a/13242177 (move semantics)
• https://stackoverflow.com/a/18766736 (std::move)
• https://stackoverflow.com/a/3582313 (perfect forwarding)
• https://eli.thegreenplace.net/2014/perfect-forwarding-and-universal-references-in-c/
• https://isocpp.org/blog/2018/02/quick-q-whats-the-difference-between-stdmove-and-stdforward
• https://medium.com/@dr3wc/understanding-move-semantics-and-perfect-forwarding-part-3-65575d523ff8
• https://stackoverflow.com/a/31281254 (rvalue references and lambdas)
• https://en.cppreference.com/w/cpp/language/value_category
• https://stackoverflow.com/q/3601602 (lvalues, rvalues, xvalues...)
• https://www.fluentcpp.com/2018/02/06/understanding-lvalues-rvalues-and-their-references/
• https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers
• https://foonathan.net/2018/03/rvalue-references-api-guidelines/

More on passing function objects by value/lvalue/rvalue as function arguments:

• https://stackoverflow.com/a/42373624
• https://stackoverflow.com/a/17626712
• https://stackoverflow.com/questions/8711391/should-i-copy-an-stdfunction-or-can-i-always-take-a-reference-to-it#comment15022295_8711479

[PeterBowman]

First console output: locomotion-20191213.txt.

[PeterBowman]

This PR has long exceeded the limit of 250 browseable commits, and helpful comments are buried deep among commit titles (https://github.com/roboticslab-uc3m/yarp-devices/pull/229#issuecomment-550268884), so I'm going to close it, at last. Also, my initial assigment was due by the end of 2019 (kinda), and I need other people to test this code extensively. Both facts convinced me to merge apocanlypse now and start a new branch with moar follow-ups at some point afterwards (and another catchy name, too). Bonus TEO feature if you can find the easter egg.

This PR was developed along with new .ini files on robot-specific repositories: https://github.com/roboticslab-uc3m/teo-configuration-files/commit/b17cea86b4ba1901de1e2fe8ccad96dc0186dac0, https://github.com/roboticslab-uc3m/asibot-configuration-files/commit/e02bfc67c363cf0353ad78921904ed50f59b1ac5.

Disclaimers:

1. Left arm CAN bus is sometimes down, I suspect a wiring issue. (cc @rsantos88)
2. Onboard TEO PCs now run the new code.
3. Mind https://github.com/roboticslab-uc3m/yarp-devices/issues/170.

Happy 2020.

PS "apocanlypse now" was totally unintended.

PS2 just noticed (Feb '20) the alternative spelling "Majorcan rework" (as in the Majorca island). Sorry, it's stronger than me.