because we need a workaround for the broken auto takeoff logic which can start the vehicle with a loiter setpoint
in this case the very first moment is still a jump but then it gets taken over by the fix gradient ramp
this can basically be reverted after the auto takeoff logic is fixed

currently when the vehicle is landed again (not after bootup) the core position controller does not run anymore
therefore the velocity limit ramp in some cases did not get reset correctly

speed limiting in auto takeoff mode only needs to be limited when the user did not take over

adresses:
there were setpoint twitches at the beginning and end of my smooth takeoff routine
it was to slow and not configurable
it was only available for automatic takeoff

mc_pos_control: switched auto takeoff to clean position control to takeoff point with gradual velocity limit
auto takeoff  was pretty chaotic and bypassed the velocity controller until some magic condition
the goal of this approach is to make the behaviour and smoothness more predictable and reuse the exact same logic for manual takeoff

mc_pos_control: pure refactor, split up core position control into velocity and thrust setpoint generation

 - a local implementation was used before which is not necessary

This got introduced with the refactoring in c5e84125

 - fixes #7050

It does not exist, neither in the actuator group docs, nor in vmount.

   Prior to onshot being added to the system. The -r of the
   "rate" command would not invoke the ioctl PWM_SERVO_SET_UPDATE_RATE
   when -r was not provided on the command line. This may have been a
   feature or a bug.

   When onshot was added to the pwm command a bug was intorduced
   that precluded the ioctl PWM_SERVO_SET_UPDATE_RATE from being
   called on -r 0.

   This commit fixes that issue, and preserves the "prio to oneshot"
   behavior of the "rate" command when -r is not specified.

In case of an invalid output mode, thread_data.output_obj was null.

vmount is automatically started now when the param is set from rcS

This automatically selects the mount aux mixer if mount is enabled via
parameters. A user can customize this by adding a file
 etc/mixers/mount.aux.mix
to the SD card.

Because further down the mixer file is set as:
	set MIXER_AUX_FILE /etc/mixers/${MIXER_AUX}.aux.mix

changes added for SPI CS defines as requested for BMI055 driver integration (e.g. GPIO_SPI1_CS_PORTE_PIN15 for bmi055 gyro) to avoid double declaration of same chip select pin

format check

Avoid dropouts, we have enough RAM there.