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

This mechanism automatically queues data into the correct thread where necessary, otherwise the method is invoked directly with low overhead.

At the same time remove the UDP socket event workaround. It is not a problem.

- 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

- Delete all old map code

- MultiVehicleManager is a Qml friendly replacement for UASManager
- Vehicle is a replacement for both UAS and AutoPilotPlugin

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.