VTOLPath: begin FSM framework for simple goals

This begins implementing a framework where there are FSMs
defined to achieve certain goals (e.g. fly to location and
land), which provides a layer of indirection between the
PathDesired UAVO and the actual navigation.

Most of the FSM logic to execute RTH is implemented. However,
none of the control algorithms are connected up yet.
VTOLPath: start to connect up control algorithms

Refactoring the control code from the main module code to
vtol_follower_control and adding the appropriate calls into
vtol_follower_fsm. The FSM still needs to be connected to the
module and the old control code ripped out.
Paths: use const pointers when appropriate

This allows using const when allowable in the calling methods.
Doxygen: enable export static for flight firmware

Since this is mostly documentation for us, documenting the internal
static methods is quite useful.
VTOLPath: more work connecting up the logic

Triggering the state transitions in the FSM when things happen is
still missing.
VTOLPath: set up the state transitions on events

Fixed up the TIMEOUT event. Added a HIT_TARGET event when the path
segment is complete.
VTOLPath: add UAVO to check the status of the FSM
VTOLPath: make sure to load settings at startup

A few other small changes. Store the activated PathDesired from the
FSM when enabling path mode.
VTOLPath: clean up variable names
VTOLPath: reenable normal position hold mode

This is a very simple FSM for position hold which simply
configures the starting location and engages it.
VTOLPath: transmitter no longer sets PathDesired

The VTOL follower module is in charge of setting PathDesired
now so the transmitter module no longer needs to. Later the
transmitter module will update information for where to move
when running in a loiter mode.
NEDAccel: move from guidance to state estimation

Preivously this was calculated in the guidance loop instead
of for every sensor update. This isn't optimal and now is
run at the full sensor rate.
VTOLPath: factor out the hold position code

This configures to hold at a requested position and stores
the location in PathDesired.
UAVOs: add new object to track desired acceleration

This is used by VTOL navigation which now computes a desired
acceleration and attempts to achieve it.
VTOLPath: init AccelDesired and small code cleanup
VTOLPath: split computing desired accel and angle

The accel desired during navigation is now computed explicitly
and will be transformed into the desired angle to achieve it
separately.
VTOLPath: use frame attitude to achieve desired accel

Since during navigation the thrust is near hover (gravity) we can
compute the attitude that should nominally achieve the desired
acceleration without any additional tuning. This should make the
overall position control loop more linear and hopefully allow
better tuning properties.

Four m/s^2 at hover corresponds to 20 degrees of tilt, and is about
linear until 10 m/s^2. So this will essentially increase the velocity
loop gains by a factor of four, all things equal.
VTOLPath: update the default settings and drop unused fields
VTOLPath: add some TODO comments
VTOLPath: make position hold not use minimum altitude

This made it shoot up when enabling PH under 15 m, which I'm
sure people will want to do.