Detect and warn when multiple vehicles use the same MAVLink system id

[DonLakeFlyer]

Related to #14808

Problem

When two vehicles are configured with the same MAVLink system id, QGC silently merges them into a single Vehicle object and the UI "jumps rapidly between vehicles" (see #14808). This comes up regularly and causes support burden. QGC should detect the situation and warn the user.

Detection mechanism

AUTOPILOT_VERSION carries a board-unique identity: uid (uint64) and uid2 (18-byte MAVLink 2 extension). Both PX4 and ArduPilot populate it from the flight controller serial. Two different boards answering for the same system id will report different uids.

There are two conflict topologies, both coverable:

1. Same id on the same link (two vehicles on one UDP port): QGC's REQUEST_MESSAGE(AUTOPILOT_VERSION) at initial connect is addressed to the sysid, so both vehicles respond. Today the second response is silently absorbed. If Vehicle watches all incoming AUTOPILOT_VERSION messages and compares against the first-seen non-zero uid, a mismatched second response is an immediate, definitive conflict signal.

2. Same id on different links (the Multi UAV connections broken #14808 case): the initial request only goes out on the primary link, so the second board is never asked. When VehicleLinkManager::_addLink() adds a secondary link, send a REQUEST_MESSAGE(AUTOPILOT_VERSION) out that specific link (direct COMMAND_LONG pack + sendMessageOnLinkThreadSafe, same pattern as Vehicle::startCalibration). Two links reporting different non-zero uids for the same sysid = conflict.

Proposed implementation

• Vehicle: handle MAVLINK_MSG_ID_AUTOPILOT_VERSION in _mavlinkMessageReceived. Build a composite identity from uid + uid2 (all-zero = unknown, skip). Store first-seen identity; on mismatch show a one-shot warning:

  Warning: Multiple vehicles are using the same system id (%1). Change MAV_SYS_ID/SYSID_THISMAV so each vehicle has a unique id.

• VehicleLinkManager::_addLink(): when link count goes above 1, request AUTOPILOT_VERSION on the new link. Unmatched COMMAND_ACK from this direct send is harmless (MavCommandQueue::handleCommandAck only logs qCDebug "Ack not in list").
• MockConfiguration/MockLink: add test-only boardUid (not persisted, default 0) used for the uid field in _respondWithAutopilotVersion() (currently hardcoded 0).
• Test: new VehicleLinkManagerTest case - two MockLinks, same sysid (setIncrementVehicleId(false)), different boardUids, assert warning via expectAppMessage(). Existing multi-link tests keep default uid 0 (identity unknown), so no false positives for legit redundant-link setups.

Caveats

• uid == 0 on both boards (SITL, some clones) = undetectable via UID; warn only when both identities are non-zero and differ.
• Warn once per vehicle to avoid spam.
• Redundant-link setups (one vehicle, two radios) report the same uid on both links - no false positive.