Make UAVCAN transport layer capable of sending/receiving messages from custom CAN protocols

[duartecdias]

A custom protocol can operate through the UAVCAN transport layer by using the CustomTransferListener and CustomTransferSender classes. This was tested using an implementation of the KDECAN protocol in the uavcan driver, in the following public branch: https://github.com/duartecdias/PX4-Autopilot/tree/pr/uavcan/kdecanProtocol

It also associates a specific CAN protocol to a specific CAN interface. Messages of a specific CAN protocol will not be sent from a CAN interface associated to a different protocol. In addition, UAVCAN messages will not be read in case the receiving CAN interface is not associated to the UAVCAN protocol. By default, UAVCAN protocol is associated to both CAN interfaces. In this case, all UAVCAN messages will be sent, and all UAVCAN messages will be read.

Additionally, the implementation also allows for a way to send/receive messages of a custom CAN protocol implemented using standard ids, without having to change the interface protocol (this assumes UAVCAN uses only 29bits - extended - Ids, as described in: https://legacy.uavcan.org/Specification/4._CAN_bus_transport_layer/).

Tests were conducted in the above public branch (https://github.com/duartecdias/PX4-Autopilot/tree/pr/uavcan/kdecanProtocol). These tests are the following:

-prepare a normal quadrotor setup in a cubeorange (can disable GPS, etc. to make it arm). Configure UAVCAN ESC parameters.
-set extra CAN device (e.g. Kitcan)
-set debug Zubax device.
-connect everything on CAN interface 1 (monitor only interface 1)
-Turn ON cubeorange. Confirm sent of motor commands while listening to extra UAVCAN devices - debug with Zubax device.
-Different parameter configurations
-ESC_PROTO: 0, CAN1_PROTO: 0, CAN2_PROTO: 0 (PASS)
Description: ESCs use UAVCAN protocol and interfaces 1, 2 are configured to use UAVCAN
Expected behavior: send UAVCAN motors commands, receive Kitcan messages
-ESC_PROTO: 1, CAN1_PROTO: 0, CAN2_PROTO: 0, KDECAN (PASS)
Description: ESCs use KDECAN protocol and and interfaces 1, 2 are configured to use UAVCAN
Expected behavior: send KDECAN motor commands (standard Ids), receive Kitcan messages
-ESC_PROTO: 1, CAN1_PROTO: 1, CAN2_PROTO: 0, KDECAN (PASS)
Description: ESCs use KDECAN protocol, interface 1 uses KDECAN while interface 2 uses UAVCAN
Expected behavior: send KDECAN motor commands (extended Ids), filter/discard Kitcan messages
-Confirm reception of KDECAN ESC feedback (PASS)
-Confirm correct operation through multiple power cycles (PASS)

[AndreasAntener]

@duartecdias thanks! I think you can squash pretty much all the commits since we had the whole KDE protocl in here initially.

The motivation for this change in our case was specifically to add KDECAN support. However I came accross numerous use-cases in the past that were simpler. Industry sensors with very basic CAN protocols exist that can be implemented alongside Dronecan like this. Either on the same interface (if rules for splitting messages can be found, the simplest split is 11bit vs 29bit identifiers) or on separate interfaces.

We're now flying with KDE ESCs and KitCANs running on the same bus without issues.