Libcanard v1.0

[pavel-kirienko]

• Update CI to Ubuntu 20.04, GCC 10, Clang 10 (also fix a couple of minor nitpicks from the new clang-tidy)
• Implement https://github.com/UAVCAN/specification/issues/94
• Implement https://github.com/UAVCAN/specification/issues/90
• Fix the NaN handling issues discovered by Scott in https://github.com/UAVCAN/nunavut/pull/115
• Bump the version number to v1.0. A long way from the first commit https://github.com/UAVCAN/libcanard/commit/6d7d39eae1d399da9bb4f62e292a5e70cbffd75d pushed in 2015.

This PR will not be merged and may incur changes until https://github.com/UAVCAN/specification/pull/97 is approved.

I debated whether it's worth renaming "subscription" into "listener" to avoid confusion:

In Libcanard, there is a bit of an implementation-specific terminology mishap: it uses “subscribe” in the sense of “tell the library that the application wants to receive this kind of transfers”; the mishap is because I couldn’t find a better word to use. Maybe I should have used “listen” instead, like canardRxListen? I wonder if we should change it.

In the end, I decided to not change it, keeping the old verbiage. If there is interest, it's not too late to do it now.

FYI @TSC21 @PetervdPerk-NXP @dagar

EDIT: it's worth noting that despite the subject-ID range review, this changeset does not render Libcanard v1.0 wire-incompatible with v0.100, excepting fringe cases of low importance. This is because the compatibility implications have been taken into account by https://github.com/UAVCAN/specification/pull/96.

[TSC21]

@dagar @PetervdPerk-NXP FYI

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

100.0% Coverage
0.0% Duplication