Filters: create the driver definitions

Currently the architecture for an S(3) filter and a generic filter
driver.  These drivers contain the callbacks to the particular
implementation.  This will still likely be interface code as there
will be steps check if the data is sufficient to run the filter
etc that is separate for each filter math.  Therefore it is proposed
most filters be implemented as three files

filter_name_core.c       -- contains the core math for the filter
filter_name_interface.c  -- contains the code mapping from the filter class
                         -- API defined here to the core.  Also defines the
                         -- driver as a flash constant instance
filter_name_interface.h  -- contains the extern define of the filter driver
StateEstimation: module that utilizes the new filter architecture

This supports SE(3) filters and generic filters currently.  In the
case of a generic, it is expected to fetch all of its own data.

An important TODO for this (and for generics) is the ability to
disconnect queues not in use.  For example since the core code
provides an infrastructure for SE(3) filters that should only be
enabled in the case of running and SE(3) filter and should be
disabled otherwise.  At this point it will probably make sense
to move process_filter_s3 into its own file within the module
(since this is still not really filter code) and add two functions

init_filter_class_infrastructure_s3
deinit_filter_class_infrastructure_s3
Filter: add id handle for current filter

This will allow future implementations to support simultaneously
running multiple instances of the same filter, and provides a
convenient way of managing the working data.
StateEstimation: remove run time selection of filter

The possibility of changing the filter at run time and having
to change the set of connected queues etc is not very easy to
deal with so for now, with little loss of functionality, just
disallow it.
Filter: deinit no longer required

Since we no longer intend to stop filters this function will never
be called.
StateEstimation: only set up SE(3) queues when needed

Since we cannot change filters at run time, only configure the SE(3)
queues when they will be used.  This removes the need to flush
queues when running other architectures.
StateEstimation: use an array of filter driver to map to UAVO

This removes the switch to select filters previously.
StateEstimation: abstract the filter class infrastrcutures out

Now each filter class has its own structure of callbacks to prepare
and process each filter.
StateEstimation: move the general SE(3) interface into the filter library

Now each exposes a general process method which then knows how to handle
all the infrastructure specific code.

An example for insgps is provided which initializes the SE(3) architecture
during its own initialization and then is called from
    filter_infrastructure_s3_process

which takes care of the common queue and uavo handling work.
StateEstimation: small fixes
Filter: move the queues into the SE(3) data structure

No need for them to be static.  There is still a question of whether
there should be one queue shared amongst the SE(3) filters which is
more efficient but more complicated logic.
Filter: update references to SE(3)+

It is inappropriate to call the filters SE(3) since they can
also estimate airspeed.
Filter: rename _s3 to _se3 to match SE(3)+ better
Filter: SE(3)+ collapses get_sensors and update

The real get_sensors for this is the SE(3)+ infrastructure one
so having a separate get/update in the particular driver just
requires caching the data for no reason and adds complexity.
Filter: add dcm hooks
Makefile: add MATHLIB and FILTERLIB paths
Filter: compilation fixes
StateEstimation: compilation fixes
Sparky: enable new architecture
StateEstimation UAVO: rename to StateFilter

This creates room for the StateEstimation module