Missing ArduPilot mavlink support to light up QGC features

### Click to Orbit support
* `MAV_CMD_DO_ORBIT`, `MAVLINK_MSG_ID_ORBIT_EXECUTION_STATUS`
* This allows you to click to specify where you want to fly to and dynamically adjust the orbit radius.

### New ROI commands
* `MAV_CMD_DO_SET_ROI_LOCATION`, `MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET`, `MAV_CMD_DO_SET_ROI_NONE` replace the single `MAV_CMD_NAV_ROI` command.
* This is mostly a reorganization of a single one size fits all command into more specific individual commands.
* This lights up these features in QGC:
* Click in map to set ROI from fly view as well as cancel
* Simpler creation of missions which use ROI. You don't need to show the user some crazy complex pile of settings to support old `MAV_CMD_NAV_ROI`
* Structure Scan complex pattern in Plan. This needs the new `MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET` support to work.

### Support for newer Camera and Gimbal commands
* `MAV_CMD_SET_CAMERA_MODE`, `MAV_CMD_DO_MOUNT_CONTROL`, `MAV_CMD_IMAGE_START_CAPTURE`, `MAV_CMD_IMAGE_STOP_CAPTURE`, `MAV_CMD_VIDEO_START_CAPTURE`, `MAV_CMD_VIDEO_STOP_CAPTURE`, `MAV_CMD_DO_SET_CAM_TRIGG_DIST`
* Mission Planning
* These allow for a simpler ui for manipulating a camera/gimbal. In QGC this capability is available on every waypoint you add. Here is what it looks like with the camera section expanded:
* QGC Joystick support allows you to control the camera and gimbal which in turn uses all of these messages: Example:
### Follow Me
* `FOLLOW_TARGET`
* This allows a gcs to implement follow me in a generic way

### Ready to Fly
* `MAV_SYS_STATUS_PREARM_CHECK`
* Shown here: https://github.com/mavlink/qgroundcontrol/pull/8968

### ArduPilot dialect messages:
* `MAVLINK_MSG_ID_CAMERA_FEEDBACK`, `MAVLINK_MSG_ID_WIND`
* QGC currently supports these but it would be nice if ArduPilot also spit out the common dialect versions of these messages so QGC doesn't need to have any specific ArduPilot dialect stuff in it.

### Surveys which capture images right up to the survey edge
* `MAV_CMD_CONDITION_GATE`
* If you just use a waypoint at the end of a transect you can't really trust it to the stop camera triggering at a reasonable place. This is due to the mission state machine moving to the next command once it hits acceptance.
* Because of this most surveys need to be planned with additional turnaround even for multi-rotor that go past the survey edge. And also you have to capture images in these turnarounds as well to get good coverage over the actual survey area edges you want.
* This in turns generates a lot of crap images outside your survey area you don't really want.
* The condition gate command holds the mission state machine such that it wont advance until the vehicle fly past an orthogonal line. This allow you to the stop camera triggering after that. Which in turn allows you to only trigger the camera inside the portion of the transect which is inside the survey area. And you can stop the camera at a more precise spot. This allows capturing images right up the transect edge in a repeatable way without having to capture in a turnaround. Generating way less crap data to process.

### New Mavlink Camera microservice
* https://mavlink.io/en/services/camera.html
* This allows a gcs to not only know if the vehicle has cameras available but also what feature the camera(s) supports.
* Which in turn allows a gcs to procide a rich ui to the user: https://github.com/mavlink/qgroundcontrol/pull/9003

### COMPONENT_INFORMATION microservice
* This allows you to get metadata about the vehicle in a known way.
* First support is for parameter metadata.
* It also includes generic spec for how to support language translations in json data. This in turn supports parameter metadata which can be translated. So if your gcs is running in German the parameter editor shows all the parameter metadata in German as well.
* Coming support for:
* What commands does a vehicle support within missions
* What are the known Mavlink FTP locations on the vehicle. This allows a gcs to provide a nicer FTP ui to move files to/from the vehicle. Thinks logs, scripts, etc.
* Flight dynamics information about the vehicle which allows a gcs to do things more intelligently/safely. For example: Currently QGC has a global app settings for VTOL transition distance. It then uses this for creating plans when you add a takeoff item and a VTOL Landing Pattern. It creates them with a valid amount of distance for the transition to take place. A global app setting for this is crap, but it's the best I can do now. The vehicle really needs to tell the gcs what the value is. There are many many other cases for information like that which would be included.
* On and on and on...
* Discussion is here: https://github.com/mavlink/mavlink/issues/1346

### `BATTERY_STATUS.charge_state` reporting
* At least from SITL testing it seems that the field is not supported
* QGC uses this information for spoken battery warnings to the user as well as high level battery indicator coloring
* Full details here: https://github.com/mavlink/qgroundcontrol/pull/9019

### `MAV_CMD_DO_CHANGE_SPEED` not implemented according to mavlink spec
* QGC has UI for change flight speeds like this:
* This is disabled for ArduPilot because if you look at these two places:
* https://mavlink.io/en/messages/common.html#MAV_CMD_DO_CHANGE_SPEED (look at the spec for param1)
* https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L751 (look at the code for param1)
* You'll see that they don't match up. QGC implements to mavlink spec, but ArduPilot doesn't.

This issue spans multiple MAVLink services and mission commands rather than naming a single implementation area. Start with ArduCopter/GCS_Mavlink.cpp, especially the MAV_CMD_DO_CHANGE_SPEED handling, and compare it with the common MAVLink specifications and the referenced QGroundControl pull requests. Done means the requested ArduPilot MAVLink capabilities work correctly and QGC can enable the corresponding features without ArduPilot-specific workarounds.

Written by the indexing model from the issue text.