It has an ICM-20602 IMU

The px4io driver was ignoring the contents of PX4IO_P_RAW_RC_NRSSI
since digital rssi wasn't working properly. This change was made in
commit 41b127d4.

Now that PX4IO_P_RAW_RC_NRSSI is returning valid values for digital
rssi, we can re-enable its use.

The controls_tick() rate exceeds the rate at which RC receivers
provide digital rssi. As such, most ticks set PX4IO_P_RAW_RC_NRSSI
to 0.

This change promotes the controls_tick() local variable 'rssi' to
static storage so that it doesn't have to be updated every tick to
keep the correct value in PX4IO_P_RAW_RC_NRSSI.

- v2.0 in PX4/Firmware (8feac973): https://github.com/mavlink/c_library_v2/commit/f2ae3ada7990d6fea25c5206057375e0c4d05672
    - v2.0 current upstream: https://github.com/mavlink/c_library_v2/commit/fb2c4f819819e2348285bc9e03ab711ceb6c4cc1
    - Changes: https://github.com/mavlink/c_library_v2/compare/f2ae3ada7990d6fea25c5206057375e0c4d05672...fb2c4f819819e2348285bc9e03ab711ceb6c4cc1

fb2c4f8 2018-07-19 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/de22395191208df6c42e243a6d7993e6a364e48a
550c3f5 2018-07-19 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/fe88d5fd12f94066a42b80ed44f7284c9b9e72a3
404f50f 2018-07-18 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/3940532218b0a1a9491d3f0fa5eec8d4555693ad

Use pre-existing MPC_HOLD_MAX_XY parameter for speed threshold.
Use _stick_expo variable for stick movement check.
Update documentation.

Use baro for height in EKF.
Use terrain hold mode in height controller.

Squashed commits:
[ed2a243] FlightTasks: Preserve control loop tuning when applying max altitude limit
[b33b947] FlightTasks: Add terrain hold function

This new mode of altitude control uses terrain following when holding position and normal altitude control when moving.

This new mode of altitude control uses terrain following when holding position and normal altitude control when moving.

Formatted whitespace and comments, standardized comment block styles and single line comments, and added capitalization and full stops to comments wherever appropriate.

When we're getting valid rssi input from the telemetry receiver,
clear the flag PX4IO_P_SETUP_FEATURES_ADC_RSSI in r_setup_features.

Rather than initializing the rssi percentage lookup table at runtime
on the heap, we would like it to be stored in flash.

This change pre-computes the rssi lookup table.

On SPM4649T receivers with firmware versions at least 1.1RC9, the
serial data will contain an rssi value in dbm, as outlined in the
Remote Receiver Interfacing document section 8.3.1.

If the value received is greater than or equal to zero, the receiver
does not support rssi data, and the incoming value will be ignored.
However, if the value is negative, we can use the rssi value.

When we have a valid rssi, it gets mapped to a percentage from 0 to
100 as expected by mavlink. This mapping is constructed as a
logarithmic function over Spektrum's published minimum and maximum
rssi values, -92dBm to -42dBm as 0 to 100:
100 Log10[1 + (x - min) * (9 / (max - min))]

This change updates all calls to the dsm input rountes to return
the rssi value.

Note that one place this doesn't work with the px4io enabled.
There is a comment left in the absence of analog rssi that:
"we do not actually get digital RSSI regs[PX4IO_P_RAW_RC_NRSSI]".
This restriction has been left in place, as removing it exposes a
problem where the frequency of the control tick is greater than
that of valid dsm frames so the rssi isn't valid every cycle.

Migrate LOGGER_BUF argument to rc.logging, group OUTPUT_MODE instances closer together by relocating UAVCAN logic block in rcS, and alphabetize hardware specific logic in rc.sensors.

   Platforms that provide HW versioning tend to have
   more FLASH and can have a PX4IO as an option.
   (E.G.) FMUv5. This change provides run time
   decision to control the safety switch on
   platfors that have BOARD_HAS_VERSIONING.

   On platforms with no versioning and have
   BOARD_HAS_STATIC_MANIFEST defined as a 1
   The decision is compile time only. When a PX4IO
   is present the fmu control of the safety is
   not built.

   Safety Switch is HW version dependent on having an PX4IO
   So we init to a benign state with the _INIT definition
   and use the non _INIT verion in the driver if the run time
   decision is we do not have a PX4IO

    The phyical led read was not returing the logical state
    of the LED. Since they are active low, when on it was
    returning 0 and the the negation operation in togggle
    was makeing that a 1 which it already was.

  Safety Switch is HW version dependent on having an PX4IO
  So we init to a benign state with the _INIT definition
  and provide the the non _INIT one for the driver to make a run time
  decision to use it.

  We also define the FMU GPIO_BTN_SAFETY and GPIO_LED_SAFETY alias
  so the px4fmu will drrive will be built with the safety switch
  code at compile time and have runtime control via the manifest

   FMUv5 supports status LEDs.

   This is the beginning of the manifest support on FMUv2/v3
   it only provide PX4_MFT_PX4IO for now.

   When BOARD_HAS_STATIC_MANIFEST is defined with a value of 1
   and the board_config provides the BOARD_USES_PX4IO_VERSION
   then the board_common will define
   PX4_MFT_HW_SUPPORTED_PX4_MFT_PX4IO

    When BOARD_HAS_STATIC_MANIFEST is defined with a value of 1
    and the board_config provides the BOARD_USES_PX4IO_VERSION
    then the board_common will define
    PX4_MFT_HW_SUPPORTED_PX4_MFT_PX4IO

   This HW does not respond to the GPIO query consistantly
   and should be treated like regular FMUv2

invert direction to point upwards and increase to 70% of throttle range between min and hover