DroneCAN: introduce table coding support

[tpwrules]

This system saves over 9K flash on Cube Orange, over 5K flash on Pixhawk1-1M, and 250-2000 bytes across MatekL431-based peripherals. DroneCAN-enabled bootloaders do not seem to profit however, so this should be disabled for them (still needs to be done).

be sure to ./waf clean, there’s an issue with the dependency chain I couldn’t figure out

Did some light performance testing using --enable-stats and @SYS/threads.txt (with increased printing precision). On Cube Orange, with one node connected, the DroneCAN thread CPU usage goes from 2.59% without this PR to 2.63% with. If I then set CAN_D1_UC_ESC_BM to 15 and CAN_D1_UC_SRV_BM to 240 to get some good traffic (~600FPS), then the CPU usage changes from 3.25% without this PR to 3.33% with. So overall a 0.08% increase in CPU usage, or a 12% increase on the thread relative to the less active baseline. Both seem eminently reasonable for the savings.

Tested using the dronecan_dsdlc test scripts and Ardupilot SITL. Also bench tested in various scenarios. Not flown it on anything yet.

Brings in these two PRs:

• https://github.com/dronecan/libcanard/pull/70
• https://github.com/dronecan/dronecan_dsdlc/pull/30

[tpwrules]

Drafted until those two PRs get merged and we have final hashes for them.

[tpwrules]

Passed some basic smoke tests using a serial GPS connected to CubeOrange-periph connected to CubeRedPrimary. Tested old/new code on one/both nodes, and tested CANFD support.

[tridge]

I think a waf configure --disable-can-table-coding would be worthwhile to help debug potential regressions