UAVCAN: fix and improve device_id logic

[Claudio-Chies]

Fixes device ID handling in UAVCAN bridges.

Solution

Refactor device ID logic across multiple UAVCAN sensor bridges to use a unified method for generating device IDs.

Changelog Entry

Bugfix: Improved device ID logic for UAVCAN sensors.

Test coverage

-[ ] open, didnt have the time yet.

[oystub]

Nice, I like doing this properly!

However, note that some of the bridges that haven't been modified still leave the bus id as 0, for example rangefinder. Up until now, the "convention" has been to just leave bus id as 0 for everything DroneCAN. If we change that, we should be careful to update it everywhere.

There is also some discussion if we actually want to separate DroneCAN buses, or treat them as as one large network. (Are two devices with the same DroneCAN ID on two different buses considered the "same" device, or two different ones?)

I did something similar in an old draft, but haven't followed it up properly:
#22880

[MaEtUgR]

This pr is related to #26126

@oystub Nice, thanks for chiming in. Let's combine these two changes and bring in consistent Device IDs for UAVCAN 👍

[Claudio-Chies]

Took inspiration from #22880, and expanded it to more drivers, thanks @oystub

[dakejahl]

@Claudio-Chies looks like there are some merge conflicts. Also try to avoid force pushing after review has started (if possible), it makes it difficult for reviewers to see what has changed between commits.

[dakejahl]

Looking good! Stoked about this, thank you!