mainly changing parameters to BlockParams, reorder them and comment

  Additional backport of c2c226be1db53dd0c1315e13bbd76ace6538eedf
  sem_holder:Clean up from Review

   Backport of upstream:

   7601a27cee348f70bebcac95e8e8372fe0651bbf David Sidrane Thu Mar 16 14:16:18 2017 -1000  sem_holder:The logic for the list version is unchanged
   3cc2a4f7c9bb495da6c59f373f8d0e7672e4ee13 David Sidrane Wed Mar 15 14:02:55 2017 -1000  sem_holder: Fixes improper restoration of base_priority
   caf8bac7fb9452f25a3297147e7b414d46e74c6f David Sidrane Mon Mar 13 22:54:13 2017 +0000  missing semi
   d66fd9f965f27eb0446d6aed24b8758674f98b53 David Sidrane Mon Mar 13 12:34:39 2017 -1000  semaphore:sem_boostholderprio prevent overrun of pend_reprios
   3c00651cfef3a0d90bb9e6522463965ad8989e6c David Sidrane Mon Mar 13 11:56:31 2017 -1000  semaphore:sem_holder sem_findholder missing inintalization of pholder
   4d760c5ea44c5f8d30a1a595800e9fbf4874e705 David Sidrane Mon Mar 13 10:46:26 2017 -1000  semaphore:sem_holder add DEBUGASSERTs
   modified 399f3067441941072664bdbfa1bfec8ff35aa449 Gregory Nutt  Sat Mar 11 08:57:34 2017 -0600  A few cosmetic changes (removed file that had nothing to do with semaphore commit by OA)
   60d8606b19a7e7c1285a0ef5e8addaaedf26b95f David Sidrane Fri Mar 10 06:38:17 2017 -1000  Priority Inversion fixes:Initalization
   6cc8f9100b3c8026e73ca738aaa5120bd78dae74 David Sidrane Fri Mar 10 06:37:46 2017 -1000  Priority Inversion fixes:typo
   360539afacc83132acdb83da8f20c468dbe4c63d Gregory Nutt  Fri Mar 10 09:30:15 2017 -0600  Priority inheritance:  When CONFIG_SEM_PREALLOCHOLDERS==0, there is only a single, hard-allocated holder structure.
                                                                                          This is problem because in sem_wait() the holder is released, but needs to remain in the holder container
   a93e46d00c1bc3447fb290b866ed21d8f9c8e146 Gregory Nutt  Fri Mar 10 08:54:50 2017 -0600  Cosmetic (missleading OA commit message) Using !pholder is now  pholder == NULL

   sem_holder: Fixes improper restoration of base_priority
   in the case of CONFIG_SEM_PREALLOCHOLDERS=0

   Original code did not take into accout that 2 holder are needed
   and failed silently when a slot could not be allocated

   The call to sem_restorebaseprio_task context switches in the
   sem_foreachholder(sem, sem_restoreholderprioB, stcb); call
   prior to releasing the holder. So the running task is left
   as a holder as is the started task. Leaving both slots filled
   Thus failing to perforem the boost/or restoration on the
   correct tcb.

   This PR fixes this by releasing the running task slot prior
   to reprioritization that can lead to the context switch.
   To faclitate this, the interface to sem_restorebaseprio
   needed to take the tcb from the holder prior to the
   holder being freed. In the failure case where sched_verifytcb
   fails it added the overhead of looking up the holder.

   There is also the additional thunking on the foreach to
   get from holer to holder->tcb.

* mc_pos_control: use just float for vel and cruise in xy

* mc_pos_control: stick map saturate magnitude to 1

* mc_pos_control: take minimum cruising speed for auto

* mc_pos_control: cruise speed triplet higher than from mc_pos_control

mc_pos_control: fix if for cruise in auto

* mc_pos_control: use PX4_ISFINITE criteria

Backport of upstream NuttX

       86400a252dcbe6e4aef3ecca000b469a0fe96b67
       08e92abb0ba744927ed0b32294859b0f47726f82
       4b65817e99cbdf04fefad883eca0e7c8a9add63c

       Improper rounding in redundant stack coloring
       routines could overwriting the TOS+1 and BOS-1
       depending on the value of CONFIG_ARCH_INTERRUPTSTACK

       This applies the compelet upstream set of fixes from
       David Cabecinhas <david.cab+bitbucket@gmail.com>

       Improper rouding in redundant stack coloring
       routines was overwriting the TOS+1 and BOS-1

       The legacy OABI 4 byte stack alingment was removed
       Only the EABI 8 byte alinement is supported
       The redundant interrupt stack coloring. up_initalize
       had the correct implemantation (last verson of patch)
       and the redundant version in the
       arch/arm/src/stmxxx/stmxx_irq.c was calculating the size
       wrong.

       This is fixed by rounding up CONFIG_ARCH_INTERRUPTSTACK
       by 4 bytes when allocated and alining on a 8 byte boundry

nuttx-patches/workarround_for_flash_data_cache_corruption.patch was
   patching a file patched in nuttx-patches/wip_inflight_to_upstream.patch

   The changes in workarround_for_flash_data_cache_corruption.patch
   will be submitted upstream once refactored (upstream coding style
   compliant and moved to correct location)

This was used together with the read() interface, but we don't use that
so the counters are wrong.

32 bits are still enough to measure elapsed times up to 1 hour.

Testing on Pixracer: I counted 73 allocations and 39 frees during bootup,
resulting in 2kB RAM usage after boot. This patch reduce this by ~0.5kB.

Fixed the block comments at the top of the source file and the help message for the script (starting at line 279) so that an underscore ("_") character is correctly described as the separator for the first message field name rather than a period character "."

* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time

* Added a separate mixer file for CAN quadrotor

* Sampling profiler improvements

* PMSP: Output more endpoints

* Matrix update

* libc usage workaround

* Removed UAVCAN perfcounters

* Matrix submodule update

This reverts commit 21e04c9f.

* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time

* Added a separate mixer file for CAN quadrotor

* Sampling profiler improvements

* PMSP: Output more endpoints

* Matrix update

* libc usage workaround

* Removed UAVCAN perfcounters

WARN  [load_mon] frsky_telemetry low on stack! (164 bytes left)

Added 168 bytes = 160 needed + 8 bytes for head room

In order to ensure correct transmission the mission system needs to default to the legacy protocol and switch to the new implementation when these conditions are met:
  * If the GCS sends a MISSION_REQUEST_INT - it will do this based on the AUTOPILOT_VERSION flag indicating int mission support
  * If the autopilot sends a MISSION_REQUEST and has the AUTOPILOT_VERSION flag for 2.0 set, the GCS should NACK it, which will make the autopilot retry a MISSION_REQUEST_INT
  * If the autopilot sends a MISSION_REQUEST_INT and the GCS does not support it, the GCS will ignore and time out. The autopilot could retry now opportunistically with the old protocol, but this is not great for lossy links.
  * If the GCS sends a MISSION_ITEM_INT - this is a fallback

 because of messages in the logs

param_save_default() could take something like 0.5s, and because the
LandDetector is running on the HP work queue, this would block other
tasks, like RC handling or drivers.

This will make sure that commmander will save the params.

This allows concurrent read access, which are much more common; reducing
potential lock contention and increasing concurrency.

Taking a lock is expensive, and the reader lock is now even more expensive.
An RCU synchronization scheme would reduce the overhead of the readers to
increasing/decreasing an atomic counter.
Thus this should only be an intermediate step until we move towards RCU.

Tested on SITL & Pixracer.

param_t is only used as an offset and we have <1000 params, so an uint16_t
is enough.
This saves roughly 1KB of RAM. We only do that on NuttX because normal
integers have better performance in general.
Previously on amd64, this was even 64bits because it was an uintptr_t.

This further speeds up param loading.

On Pixracer via USB, it's possible to send up to 11 at once before the TX
buffer gets full, so there is still enough free bandwidth left.

This speeds up parameter loading. Slow links like telemetry are unaffected,
since the mavlink loop runs only with ~100Hz.

Tested on various links, like:
- telemetry link
- pixracer WiFi
- pixracer USB
- SITL

The white led state would continue during calibration, now it return to the previus state

with priority and blink period

Previously the retry would not actually have been sent if nothing had been received in time.

* Remove remove safty swtich LED from FMU control

* Differentiate GPIO_BTN_SAFETY_FMU  from GPIO_BTN_SAFETY