Actually, changed so showDialog figures out on its own if it should use available height or full parent height. The variable is now set by the main window, which controls which view is being shown.
I commented off some code in ParameterEditorDialog.qml as it is not properly handling the dialog and causing it to get "stuck".

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

instead of         onEntered: { __forceHoverOff = false; hoverTimer.start() }

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

without a check this code should be a bit faster, and thus
the check was really uneeded.

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

This makes it possible to select more than one value
to be used in the parameter configuration, and since
the parameter is actually a bitfield - this is the
correct thing to do.

one of the drawbacks is that in the parameter listing
the value of the Fact will not be displayed as string
anymore, but with 'undefined: numerical-value', that is
the OR combination of the applied values.

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Map control use different border color based on map type

Note that a change in zoom signals a `zoomLevelChanged` event; this in turn triggers `FlightDisplayViewMap` which sets the property changed in this commit to
```
onZoomLevelChanged: QGroundControl.flightMapZoom = zoomLevel
```

This triggers the following message in Application Output: `onZoomLevelChanged: QGroundControl.flightMapZoom = zoomLevel`.

This was the case before and after this fix, I don't know if that's a real issue though

- Convert mission load/save to it
- Allow parameter load/save on mobile