This commit is the groundwork to fix the power LED
   blinking on V5

   Background:
   ----------
   Early boards only had an AMBER LED that was used to
   indicate a High Load condition.

   This change defines the new logical inteface
   the LED_<color> should not be used in application
   code moving forward, only the minipulator macros
   should be used.

       Logical usage             Legacy default
      ------------------------+-------------
       BOARD_OVERLOAD_LED     | LED_RED

   Later boards defined BOARD_HAS_CONTROL_STATUS_LEDS
   and added the use of a BLUE and GREEN LED that were
   used as follows:

   Logical usage             Legacy default
      ------------------------+-------------
       BOARD_ARMED_LED        | LED_BLUE
       BOARD_ARMED_STATE_LED  | LED_GREEN

   With this PR a board may now define _only_ a subset
   the leds and map them at the board level to the
   color LED it wants to use.

       Logical usage             Legacy default
      ------------------------+-------------
       BOARD_OVERLOAD_LED     | LED_RED
    when BOARD_HAS_CONTROL_STATUS_LEDS is defined
       BOARD_ARMED_LED        | LED_BLUE
       BOARD_ARMED_STATE_LED  | LED_GREEN

   If any of the BOARD_{OVERLOAD|ARMED|ARMED_STATE}_LED are not
   defined. The code output generates a null action for that
   LED.

Fixes bugs causing learned or GEO lookup declination to not be used in some circumstances.

https://github.com/PX4/ecl/pull/518
https://github.com/PX4/ecl/pull/520

to save the time running the installer for every build
which was necessary before because the folder exceedes
the maximum of 1GB cache of the appveyor free plan

- mavlink v2.0 in PX4/Firmware (0b3f4014bf751cde2a08abb578c10ae5606404b1): https://github.com/mavlink/c_library_v2/commit/32dcf73bb24516dc0d52119e624fda8987a03f62
 - mavlink v2.0 current upstream: https://github.com/mavlink/c_library_v2/commit/408a7bedf3074bcae265ea0ce8ec5bb3519ed272
    - Changes: https://github.com/mavlink/c_library_v2/compare/32dcf73bb24516dc0d52119e624fda8987a03f62...408a7bedf3074bcae265ea0ce8ec5bb3519ed272

408a7be 2018-11-13 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/f3e60ba1ca9c458364cc9538499a1335aa2feb5e
c18232f 2018-11-12 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/2c52b06e125f88f6b674db112f127dc35d7a9c71
49a94c7 2018-11-09 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/c788ca3e143fbb0fd1f90a14fd2a473673b50973
0c4b296 2018-10-29 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/387c0fd71547d71f1e89578c8ef78c6bac8d6094
40bfa6c 2018-10-29 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/4590822ebde2a5737504c832669d74310afa4b8e
ad2c30b 2018-10-26 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/38ecb35a3e3e6702b5522ac33188a53cc1fe698e
9fbf059 2018-10-24 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/30b63eb0c20160ddeeca3eef4238f370d3f3d43f
7915ad4 2018-10-23 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/2c6a8807b85317275c9d027afba7f646eb7db961
4371e84 2018-10-23 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/573e35231804ad775796472bcdcd331b4479cf4d
d67e172 2018-10-22 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/40f83b2d4ff43fa65d08bb5ebeb9186dc2e8c2a6
852935c 2018-10-16 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/d683ddc28b1254ea8645dd2a18e5765b6bab0eba

This triggered POLLHUP too early on Mac.

* mavlink: yaw should wrap at 2 pi, not pi
* mavlink: use newer rad/deg conversion

Unlike pipes, unix sockets provide bi-directional
communication with each connected client.

- No need to generate a unique uuid per client anymore.

- The client doesn't have to create its own pipe anymore.

- Since there is no risk of multiple client's writes getting mixed up,
  messages don't need to fit in a single write anymore, removing the
  limit on command length.

- Since the server can detect a connection closing, the client no longer
  needs to handle signals. When the client is killed, the connection is
  automatically closed, which will cause the server to kill the related
  px4 thread.
  Since this does not rely on handling signals and the client sending an
  additional message, this is much more reliable.

- Client is no longer a singleton.

- The protocol is simplified. Standard output is directly written to the
  socket back to the client, without wrapping it in any protocol
  message.

- Because of the simple protocol, one could now even use netcat to run a
  px4 command:

    $ echo hello | netcat -UN /tmp/px4-sock-0

Also removes a few race conditions.

Also update some comments.

In case we activate the task and don't have a locked yaw, we should
initialize the yaw setpoint with NAN to avoid any abrupt changes.

This is especially useful for testing (the vehicle must behave correctly
even at high tilt angles).

When switching back from rate to attitude control, the code depended on a
vehicle_control_mode topics update, but the publication frequency of that
is low. So the switch was noticeably delayed.

- better in terms of dependencies:
  - the position controller code depended on position topics for yaw
  - mc_pos_control does not have to be run for Stabilized mode
- the code path is much simpler, and thus less error prone. This is
  especially important since Stabilized is often used as a fail-safe flight
  mode.

use nullptr for instance to make sure we always get the first instance.

Previously when switching e.g. from stabilized from acro, the stabilized
flight task kept running and publishing setpoints.
Luckily it caused no problems, but the log showed arbitrary attitude
setpoints.

Revert "pwm_out_sim lazily publish actuator_outputs"

This reverts commit bcad940a.

As there is only one bit used in 'flags', and it is only used in case
update_interval is not null, we can move the bit to UpdateIntervalData.

The size of UpdateIntervalData does not increase (on 32 bit).

Reduces RAM usage by 3.6KB (tested on a Pixracer).