NavigationWizard: create stubs for navigation wizard
Setup plugin: add the navigation wizard and register in menu
SetupWizard: rework abstraction to support other wizards

Right now all the wizard pages are given a SetupWizard in their
constructor which precludes using this architecture for other
wizards.  Almost all of the time they don't really need to use
the parent wizard and only access it because either
   1) it is a QWizard for things like calling close
   2) it is a VehicleConfigurationSource and they want to work
      with that

The VehicleConfigurationSource should probably be abstracted out
of the actual wizard so the wizards _have_ a VehicleConfigurationSource
and not so that they _are_ a VehicleConfigurationSource.  This is
generally a better design pattern when possible.  It also means we
can easily drop in different configuration sources with a standard
API which can come from the board plugin system.

For now these changes start that by making the AbstractWizardPage
initialize with any QWizard.  For backward compatibility getWizard()
dynamically casts back to a SetupWizard* so all instances of using
this should be changed to getQWizard() when possible.
NavigationWizard: do not inherit from VehicleConfigurationSource

The VehicleConfigurationSource has a bunch of pure virtual functions
that make sense for a general SetupWizard but not for specific aspects
like navigation.  So the navigation wizard does not inherit from it
anymore.

The SetupWizard functions using this should be moved _into_ the
VehicleConfigurationSource and it should forward calls (or let
the pages directly access its VehicleConfigurationSource object).
AbstractWizard: add getQWizard getObjectManager methods

The getQWizard is based on the previous commit comments.  Make a method
to get the minimal interface required to establish a better abstraction
from wizard methods and configuration methods.

The getObjectManager helps for direct access to objects.  For consistency
with the current implementation it should be used judiciously because all
the code to actually write to the flight controller is consolidated in the
VehicleConfigurationHelper class.  So really this should only be used for
getting settings.
SetupWizard: use getObjectManager() in the outputCalibration page
NavigationWizard: add failsafe page

This page checks that the user can toggle failsafe mode by turning
the transmitter on and off
SetupWizard: remove unused files
Nav wizard: check in separate plugin

This is currently a duplicate of the Setup Wizard
NavWizardPlugin: update class name
NavigationWizard: more compilation fixes
SetupWizard: revert to version from next

Navigation wizard parts are in a separate plugin now.
NavWizard: get the plugin loaded
Wizards: use general flight controller name

Previously still said OpenPilot controller but we support
many more than just that.
NavWizard: use the previous SavePage at the end
Navigation Wizard: clean up failsafe verification

Now multiple cycles are required before the next button is
enabled which makes sure the initial state doesn't change
things.
Navigation Wizard: group with other wizards
NavWizard: improve failsafe page text
NavWizard: set some of the data
NavWizard: clean up text before saving