The startup file rc.board is copied to the build/../genromfs folder
after the pruning of the files happened. Thus, about 2000 bytes of
comments and whitespace were included in the ROMFS.

This commit moves pruning of the files in ROMFS to a separate cmake
custom command which happens after the ROMFS files have been copied and
the extra files have been added.

Testing showed that this change only affected the rc.board file as
expected.

It is only actually sent out when the orbit is running.

tone_alarm was started before the parameters were loaded, and the first
tune was played before that as well. CBRK_BUZZER was then read as default,
ignoring the user-configured value.

We now start tone_alarm after we load the parameters. Note that a
previously published startup tone or SD card error will still be played.

This is more accurate, because if we use -1000 as lower bound, a very large
yaw command can reduce thrust more than needed.

The difference can be seen in the following example
(with roll/pitch airmode):
p_dot_sp = -1.0 # roll acceleration
q_dot_sp = 0.9 # pitch acceleration
r_dot_sp = -0.9 # yaw acceleration

makes it easier to compare.

Yaw airmode w/o arming switch is most likely not what you want and will
lead to surprising results.

To run:
cd src/lib/mixer
make tests

This will validate the C++ implementation by taking the python
implementation as ground-truth. It runs through various actuator control
command values for all airmode variations and several mixer types.

The python script also allows to prototype new mixer algorithms.

It is not integrated into the existing build system, because it's easier
to use that way, with less dependencies, and faster testing workflow.
It could however be a bit more integrated.

Reference: https://github.com/Auterion/Flight_Control_Prototyping_Scripts/tree/master/control_allocation

- avoid including <px4_defines.h> from the math headers
- avoid driver include <drivers/drv_mixer.h> from the mixer

Provides a more generic desaturation algorithm, making it easier to
handle the different mixer strategies.

python reference implementation:
https://github.com/Auterion/Flight_Control_Prototyping_Scripts/tree/master/control_allocation

The behavior for non-airmode and roll/pitch airmode should be the
same as before.

CPU load is slightly higher for the non-airmode case (+0.5%), for airmode
it is the same.

This updating of the driver setting is for EMI issue with GPS and FCC.
   With this setting the clock is sinusoidal

   N.B. sd_bench fails on SanDISK HC, but Passes SanDISK **HC1** and
   Kingston cards.

   ****Use HC1 or Kingston cards!***

   Testing done on SanDISK HC all failed sd_bench with Drive/Slew other
   than default and _PIN_OUTPUT_FAST|_PIN_OUTPUT_HIGHDRIVE

	_PIN_OUTPUT_FAST|_PIN_OUTPUT_HIGHDRIVE    Square noisy, pass SanDISK HC
        _PIN_OUTPUT_FAST|_PIN_OUTPUT_LOWDRIVE     Square noisy, pass SanDISK HC
        _PIN_OUTPUT_HIGHDRIVE|_PIN_OUTPUT_SLOW    sinusoidal fail SanDISK HC, pass SanDISK HC1
        _PIN_OUTPUT_LOWDRIVE |_PIN_OUTPUT_SLOW    sinusoidal fail SanDISK HC, pass SanDISK HC1
                              _PIN_OUTPUT_SLOW    sinusoidal fail SanDISK HC, pass SanDISK HC1

   Delete auto generated vars, and others that were missed.

- partially addresses #11017

_Stof, bsearch, param_find_changed