mc_pos_control_main smooth takeoff: enable position-xy/yaw control once above 0.5m from takeoff reference

just keep thrust vector pointing upward

smooth-takeoff. This is only required if someone writes a FlightTask where both position
and velocity setpoints are finite

    - libuavcan in PX4/Firmware (8958b42dada1e14f27c287a59b51ff26e90486a1): https://github.com/UAVCAN/libuavcan/commit/479d144ded9d5d16e234121ef9511b9ca9dfdac5
    - libuavcan current upstream: https://github.com/UAVCAN/libuavcan/commit/6174b8c10a2dbf47076ca7a7b5820a4c36c8a988
    - Changes: https://github.com/UAVCAN/libuavcan/compare/479d144ded9d5d16e234121ef9511b9ca9dfdac5...6174b8c10a2dbf47076ca7a7b5820a4c36c8a988

    6174b8c 2018-10-06 Pavel Kirienko - Link to the new forum

vehicle state.

refactor use_obstacle_avoidance method

acceptance radius from the paramters and overwrite it if the mission item
has set acceptance radius

The hover thrust param also changed the thrust scaling in Stabilized mode.
However if the hover thrust is very low (e.g. below 20%), the throttle
stick input becomes very distorted.

- no airframe changes the default
- it does not make much sense to be able to configure the 0.1 threshold
  but the 0.3 threshold for ground contact detection cannot be configured.

radio_status: change 'fixed' field name to 'fix' so it does not clash with 'fixed' floating-point notation on the IDL generation

The user does not need to configure this, so we can hide it from the UI.

This fixes the build with Python 3.7.

desired such that it's possible to use it in manual modes

A filtered update update interval is calculated for each receiver.
If dissimilar interval data is detected, blending occurs when data is received from the slower of the receivers.
If similar interval data is detected, blending occurs when receiver data with similar time stamps is available.
If no data is received from either receiver for longer than 300msec, then no blending will be performed and the most recent data will be used instead.

- previously it was possible to get a Position Control rejected message
  without further advice what was actually wrong. So now we report warnings
  even if gps is not required for arming (which could be annoying too...).
- the GPS failure message was very generic, making it hard to debug the
  cause. Now we check every bit and send an appropriate warning

All strings were checked not to exceed the maximum length of 50 characters.

estimator status init is not required.