MAVLink: support mavlink 2.1 32 bit system IDs

[tridge]

Summary

Implements 32 bit system IDs

See also:

• implement 32 bit system IDs pymavlink#1229
• mavproxy: allow 32 bit MAVLink system IDs MAVProxy#1704
• pymavlink: update for 32 bit system ID support mavlink#515
• added rough mavlink 2.1 proposal mavlink/rfcs#20

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Description

This implements mavlink/rfcs#20 but with 32 bit system IDs to allow for IPv4 addresses to be used for system IDs. This should make large drone light shows easier.
I also plan on making full 32 bit integers work with mavlink parameters to make this more practical for real IPv4 addresses. That will be a separate effort

Some open questions:

• should we put target_system&0xff in the uint8_t target_system field in messages or should we put in 0? This PR uses 0
• the lua script changes are tricky as the mavlink receiver gets the raw C structure which is now 3 bytes larger. Should we add compatibility code so the new lua script handles both forms? UPDATE: I've added compat code

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff and cross-checked by a second AI reviewer (Codex). Please sanity-check before acting.

Verdict: REQUEST CHANGES — the widening is coherent and careful (param width conversions, extended-header targeting, routing, Lua dual-layout handling, and the 100000-sysid autotest all check out), but three sysid truncation sites remain in-tree that break when a >255 sysid is actually used:

• libraries/AP_CANManager/AP_MAVLinkCAN.cpp:298 — local uint8_t system_id copies the widened can_forward.system_id (:337), so CANFD/CAN frame replies (:347/:354) are misaddressed for requesters with sysid > 255. The struct field in AP_MAVLinkCAN.h was widened by this PR but the .cpp local copy was missed.
• libraries/AP_Generator/AP_Generator_Loweheiser.h:106 — uint8_t sysid: assignment truncates at AP_Generator_Loweheiser.cpp:691, the source-match guard at :638 then misbehaves, commands at :473 target the truncated ID (the QBB log at :507 would also need widening).
• libraries/AP_OpenDroneID/AP_OpenDroneID.cpp:138 — uint8_t val = gcs().sysid_this_mav(); truncates a high local sysid for the ODID Basic ID broadcast.

Positive notes: the handle_statustext() chunking fix (compid was compared against last_src_system) is a genuine drive-by bugfix; packet_overhead_chan()'s conservative extended-header reservation is sound. Procedural: needs the modules/mavlink bump merged with/before it, and a rebase (check-merge-commits failing). NOTE: AP_Follow's width conversion runs lazily on first update_estimates() rather than at init — a tiny window where a param fetch sees the default; harmless but worth knowing.