Added remote OpenGL drawing in 3D view. Any external application can draw to the 3D view via the protobuf implementation of GLOverlay messages.

This commit unifies the supported baud rates completely across QGC and OSes.

Fixed error (in VS2010) about lacking a return value introduced in 6a55b6cd.

Modified SerialLink.cc so that it follows the same cross-platform restrictions as the QSerialPort library it relies on.
Windows compilation was broken during 94e91013, which is what prompted this refactoring.

Introduced persistence in RGBDview, needs debugging, fixed a bug in param reading in the simulator, pushed message sender a bit forward, not working yet

Removed outdated MAVLINK v0.9 version as QGC does not work with this version. Added feature to import COLLADA terrain model and visualize model in 3D view.

Also updated all the units for the heartbeat values that are exposed to the realtime plotter to follow the suggestions laid out by the documentation for valueChanged().

cause: check for null pointer had no effect (static memory)
solution: fill mavlink messages (and thus) message type with 0xff. this patch assumes that message ID 0xff is never used
positiv side effect: qgroundcontrol uses 2% less cpu on my machine (eeepc)

Removed some dead code.
Added more valueChanged() signals to account for every data type. This moves the conversion over into the valueChanged receivers, which while it will require more slot-functions, makes it easier to add more code as any necessary conversion is done internally to the slot and so the signaler doesn't need to know the details.
I also added some more details on the types of units expected by valueChanged().

Exposed HEARTBEAT.system_status and HEARTBEAT.base_mode to the realtime plotter widget via the valueChanged signal.

sending GPS sat information via a low-bandwidth link like the UM96 @ 9600 baud should also work at low frequencies like 0.2 Hz

Changed the drop rate from a SYS_STATUS message to follow the MAVLink specs along with some extra range checking.

Added a workaround to the mission management code where it would only accept messages addressed to the MAV_ID_MISSIONPLANNER component. This was causing problems with the send-loss value being calculated, so I decided to add this until a proper solution can be developed.