The form of the PX4  GUID is as follows:
   offset:0         1         2         -           17
      <ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>

   Where <ARCH MSD><ARCH LSD> are a monotonic ordinal number assigned by
   PX4 to a chip architecture (PX4_SOC_ARCH_ID). The 2 bytes are used to
   create a globally unique ID when prepended to a padded CPU ID.

   In the case where the CPU's UUID is shorter than 16 bytes it will be
   padded with 0's starting at offset [2] until
   PX4_CPU_MFGUID_BYTE_LENGTH-PX4_CPU_UUID_BYTE_LENGTH -1
   I.E. For the STM32
   offset:0         1     2  3  4  5  6             -            17
     <ARCH MSD><ARCH LSD>[0][0][0][0]<MSD CPU UUID>...<LSD CPU UUID>

   I.E. For as CPU with a 16 byte UUID
   offset:0         1         2         -           17
     <ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>

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

due to limited flash space.

A buffer size of the gps drivers got reduced by 100 bytes.

This uses now the same sleep time logic as mavlink, depending on the
baudrate.

CPU usage on a Pixracer for different sleep times:

#num reads/sec    sleep time         CPU usage
17-18             2.8ms              0.233-0.31% (this PR)
12                5ms                0.155-0.3%
9-10              10ms               0.155-0.233%
6                 20ms               0.155-0.233% (previous)

to fix Cygwin upload. It failed silently but when catching it prints
"non-standard baudrates are not supported on this platform".
Discussion about platform independet FTDI detection is in issue #10429.

Also some general minor sanitizer improvements.

    - DriverFramework in PX4/Firmware (1ce7e8d89a16262afe07d7487e55a2ec05985627): https://github.com/PX4/DriverFramework/commit/721ace3e797f141f0950144bace6a30f6aa1325a
    - DriverFramework current upstream: https://github.com/PX4/DriverFramework/commit/9f456acb3c8d70df3cd8906123388935dd6303f6
    - Changes: https://github.com/PX4/DriverFramework/compare/721ace3e797f141f0950144bace6a30f6aa1325a...9f456acb3c8d70df3cd8906123388935dd6303f6

    9f456ac 2018-09-30 Bart Slinger - Increase DriverFramework priority to SCHED_PRIORITY_MAX

 - fixes #10599

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.

So that they can be used for reporting errors.

1 was too high to pass the EKF2 test (EKF2_REQ_SACC which is 0.5 by default)
and thus switching into position mode in HIL was not possible.

 - revert once #10590 is resolved properly