- start from a velocity setpoint pushing into the ground
to ramp from idle thrust up.
- start with a bit higher velocity setpoint threshold to make
sure the vehicle has a chance to really get off the ground.
- calculate ramp slope from initialization setpoint to the desired one
instead from zero to the desired. this ramps up quicker when you demand
a very small upwards velocity like the AutoLineSmoothVel and
ManualPositionSmoothVel tasks do at the beginning.
- don't stay in the takeoff ramp depending on the land detector, this
is unnecessary.

The comments and variable names were partly misleading.
I grouped all members, hopefully gave them more
understandable names and adjusted the comments.

There were two rather confusing function calls one to check
if smooth takeoff needs to be ran and one that updates it.
I combined them and documented the interface correctly
making the parameters non-reference const floats.

using parameter_update.py script

velocity smoothing library to create a jerk-limited trajectory along the
Z axis. This FlightTask is used when MPC_POS_MODE = 3.

Before if you were above the maximum altitude you could not command to
go down anymore until the position controller had overshoot to under the
maximum altitude again.

mc_pos_control - reduce smooth_velocity_takeoff default threshold, set initial takeoff speed to 0 and remove useless else

   Suport upstream change in nuttx.

There were accidents because when missions lead through an obstacle
and it should be avoided but the setpoints from the external obstacle
avoidance module are suddenly missing the mission is continued into the
obstacle which results in a crash.

PositionControl: update comment about the order of thrust and position

mc_pos_control: reset setpoints to NAN if required

MulticopterLandDetector: consider to be landed if vehicle is not armed

mc_pos_control: initialize landing struct with landed

mc-pos-ctrl: adjust thrust-setpoint and yaw during ground-contact/maybe-landed without capturing
that information within vehicle-local-position-setpoint topic because that information
does not belong to user intention

PositionControl: set local position/velocity setpoint to NAN if not used in the control pipeline

mc-pos-ctrl: Fill vehicle_local_position_setpoint_s structure as follow:
The message contains setpoints where each type of setpoint is either the input to the PositionController
or was generated by the PositionController and therefore corresponds to the PositioControl internal states (states that were generated by P-PID).
Example:
If the desired setpoint is position-setpoint, _local_pos_sp will contain
position-, velocity- and thrust-setpoint where the velocity- and thrust-setpoint were generated by the PositionControlller.
If the desired setpoint has a velocity-setpoint only, then _local_pos_sp will contain valid velocity- and thrust-setpoint, but the position-setpoint
will remain NAN. Given that the PositionController cannot generate a position-setpoint, this type of setpoint is always equal to the input to the
PositionController.

mc_pos_control: switch to designated initializer for landed

It's less error prone because it produces an error on every discrepancy.

When we poll on vehicle_local_position we shouldn't do yet another
orb_check but copy it first up.

- Handled in the flight task

- landing_gear: refactor state name
- Add the keep state to the landing gear message
- Adapt FlightTaskManual, FlightTaskAutoMapper, mc_pos_control,
to review message definition

- Addressing review comments

- It takes the input from the constrains from the active flight task

- An new message is created just for the landing gear
- The old logic is repalaced by publishing this new topic

Necessary because NuttX defines pollfd differend from
the POSIX standard. The difference of field order makes
use of C++ designated initializers to compile for both
platforms impossible.