Adding Sugnan Prabhu as maintainer for Intel Aero.
With great power comes great responsibility!

This is more flexible, allowing a combination of sets.

The default enables the same set & rates as before

DroneCore uses the attitude quaternion, and not the attitude
Euler angles.

The gimbal attitude is required by DroneCore.

aerofc-v1 uses a STM32F429V not STM32F427V.

There was and extra "nuttx" dir:
	cp: cannot stat '/home/lucas/p/dronecode/PX4/Firmware/build/aerofc-v1_default/NuttX/nuttx/nuttx/.config': No such file or directory
	FAILED: NuttX/CMakeFiles/menuconfig

And the board fixup being executed from the wrong working directory:
	nuttx-configs/aerofc-v1/nsh/defconfig
	fatal: Path 'nuttx-configs/aerofc-v1/nsh/defconfig' does not exist in 'HEAD'

- initialize rc lost with true
- refactor for simpler downstream code-plugin
- allow for the addition of different binding commands
- fix st24 RC lost logic

Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>

The config mode uses high rates for many streams, leading to high CPU usage
(9-10% for the mavlink sender). The normal mode contains almost the same
set of messages but at lower rates.
This reduces the CPU load on a Pixracer by 3-4%.

fadfdasf

This change limits all mission items to the maximum flight altitude. The mission will still be executed and flown,
but the vehicle will never exceed the mission altitude. This ensures the vehicle can always reach the mission
items. Wether or not the entire mission should be rejected if it falls outside of the fenced area is enforced
in the mission feasibility checker function.

The IST driver did not optimally check the calibration result and could trigger false positives if the mag data aligned with wrong signs

This commit is an attempt to fix a race condition happening on takeoff
between the land detector and the multicopter position controller.

Previously, an auto-takeoff leads to the following events:

1. A takeoff setpoint is given.
2. The thrust setpoint spikes because we don't enter smooth takeoff yet.
3. The land detector detects a takeoff because of the high thrust.
4. The position controller sees the landed state transition and
   initiates the smooth takeoff. Thrust goes back down.
5. Depending on control gains the takeoff is successful or fails
   if the smoothing takes too long which causes thrust to be too low, so
   the land detector detects land again.

The two obvious problems with this are:
- The intermittent spike.
- The failed takeoff because of the smoothing leads to a delay..

With this change, the logic for a takeoff detection is moved from the
land detector to the position controller.

The events are now:

1. A takeoff setpoint is given.
2. The position controller detects the takeoff setpoint and initiates
   the smooth takeoff.
3. As thrust ramps up, the land detector detects the take off.

In the same way, we now detect the intent to takeoff in manual,
altitude, control, position control in the position controller instead
of in the land detector.