fix(mavlink): Allowing custom modes to request offboard setpoints via the external mode registration

[jonas-eschmann]

Solved Problem

Fixes #26768

Solution

This PR implements Alternative 1

        ┌─────────────────┐
        │  Custom Mode    │
        └─────────────┬───┘
                      │ register_ext_component_request.request_offboard_setpoints
        ┌─────────────┼──────────┐
        │ Commander   |          │
        │ ┌───────────▼────────┐ │
        │ │ ModeManagement     │ │
        │ └────────────────────┘ │
        └────────┬───────────────┘
                 │ vehicle_status.accepts_offboard_setpoints
                 ▼
        ┌─────────────────┐    MAVLink: SET_POSITION_TARGET_LOCAL_NED
        │ MavlinkReceiver │◀───────────────────────────────────────────
        └────────┬────────┘
                 │ trajectory_setpoint
                 ▼
        ┌─────────────────┐
        │  Custom Mode    │
        └─────────────────┘

Changelog Entry

For release notes:

Feature/Bugfix #26768 Allowing modes that use the external mode registration to receive offboard setpoints

Alternatives

Approach	Pros	Cons
GrooveWJH PR: The Mavlink Receiver observes the external modes through the request topics	No modifications to vehicle status	The Mavlink receiver gets entangled with the mode registration
Alternative 1: request_offboard_setpoints in the external mode registration. This needs to be reflected in the vehicle_status because that is the main source determining the behavior of the mavlink_receiver.cpp	Cleanest long-term solution	adds flag to vehicle_status
Alternative 2: Make mavlink_receiver.cpp always emit trajectory_setpoint for external mode IDs	one-line fix	If there is ever an in-source mode that uses the external mode registration but also generates trajectory_setpoint itself, they could be conflicting. AFAIK currently only mc_raptor and mc_nn_control use the external mode registration from the inside and for external modes it does not matter anyways, so this is not an issue

I believe Alternative 1 is the the right approach here. It unambiguously implements the forwarding while neither entangling mavlink_receiver.cpp with the mode registration (in contrast to GrooveWJH PR) nor adding assumptions about the NAVIGATION_STATE_EXTERNAL{1-8}

Context

External modes like mc_raptor and mc_nn_control that use the external mode registration benefit greatly from being able to receive offboard setpoints via MAVLink