To have both order from the GCS and drone messages in logs
So that it's possible to analyze the complete exchange between QGC and the
drone.

- Add a signal emitted by writeBytes of each LinkInterface
- Connect this signal to MAVLinkProtocol::logSentBytes in LinkManager
- MAVLinkProtocol::logSentBytes will parse and log messages sent from
  QGC

Prevent counter overflow

Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

Fixed the core MAVLink receiver. Among other things, it wasn't accounting for fragmented messages.
Fixed code that monitors messages received (and lost)
Added a section within the MAVLink panel to show the current status (for the current vehicle)
Remove some old, unused exposed interfaces

* Flight modes still not implemented. Waiting on message change.
* Also includes various cauterization of UI things which should not be
available on high latency link.

This reverts commit 52160d80.

This extension introduces a complete version handshake mechanism which will detect wether the vehicle AND the complete link / routing infrastructure support MAVLink 2. If they do, QGC will switch to the highest protocol version supported by all connected vehicles. If a new vehicle connects, it will re-negotiate the highest possible version. This means that we error on the side of compatibility, which later can be easily changed.

No more user prompting

Use component id from heartbeat

_finalize methods need information which is not available if all you
have is a mavlink_message_t

- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

Instead us a Toolbox concept which hangs off of QGCApplication

Link ids were being used interchangeably with the mavlink channel for
the link. Link ids handed out as a numerically increasing integer. Once
the counter went past MAVLINK_COMM_NUM_BUFFERS all hell would break
loose and cause memory corruption.

Also many LinkManager API changes to further isolate all link
management inside LinkManager.