f4 pios_i2c: fsm rewrite to get rid of all errors and special cases
all pios_i2c: moved event enum definition into private header
all pios_i2c: removed first_txn as it was unused
all f1 targets: use CMSIS3 headers
pios_delay: refactored into PiOS/Common
pios_delay: reenable access to DWT register right before usage
This solves debugging issues when breaking into a delay loop.
pios_delay: fix overflow in PIOS_DELAY_GetuSSince
pios_delay: changed us_modulo calculation to two steps
fw_sparkybgc makefile: added pios_delay.c
pios_delay: ensure that PIOS_DELAY_GetuSSince() is overflow safe
Merge pull request #924 from lilvinz/pios_delay_fixes

Pios delay fixes
Merge pull request #946 from lilvinz/i2c_driver_fixes

RFT: F4 I2C driver FSM fixes
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