Limit all queries to areas smaller than 500km^2. If an area of interest is greater, clip to 500km^2 centered on current ROI's center.
Removed the identifier "Airmap" from error messages coming from Airmap.
Added a clipping function to QGCGeoBoundingCube (clip polygon to given area)

Updates in general was only done if a POI changed. This caused changes related to something other than a change in POI to be ignore. The code now "resets" the POI when such changes occur (change of ruleset for example).
Ruleset selection is was not persistent. When reloading the list of rulesets for a given region, any previously selected ruleset would be reset to defaults.
Also fixed several new clang warnings.

Implementing authorization management

Moved flight planning away from "Flight Management" to its own class. Planning does not need a connected vehicle.

AirspaceManager is now exposed by QGroundControlQmlGlobal instead of Vehicle (available all the time)

An rather unfruitful attempt at consolidating Advisories and Airspaces (they are both arrays of Airspaces). No such luck as they vary wildly. In the end, I'm now exposing the restrictions (Polygons) directly (and inherently) instead of copying them.
Tweaked polygon overlay colors and borders.

Break apart string of classes into their own files as all in one file became unwieldy
Expose Airspace data in a QML ready format
Split global Airspace from AirMap (Only now I figured out the reason for the pure virtual root classes)
Refactored a bunch of things to make it consistent and/or obvious

Move all airmap related stuff to its own directory

You need to adjust the 'AIRMAPD_PATH = path_to_airmapd' in
qgroundcontrol.pro to make it compile.

And sorry for the huge commit :/

- add multi-vehicle support: each vehicle has now a per-vehicle AirMap
  object that takes care of flight creation, traffic & telemetry
- add a base class API layer so that the interface between QGC and the
  AirMap implementation is clear, and easier to change
- removes polygon upload to vehicle (needs a better solution)

This includes polling for a flight permission.
The steps are:
- get pilot id (new API requires to provide it, even though it does not
  make much sense)
- create a flight plan
- call the briefing (to check if SITA registration id's are valid)
- call the submit -> returns the actual flight id
- poll on the briefing until the flight gets approved

Since there can only be one flight, on startup, we list the pilot's flights
and end the one that ends in future

- start telemetry if there's a valid flight id and the vehicle armed
- only the Position message is sent for now

This is just to test, will need much better integration