Copter: send sonar distance to GCS via MAVLink

At the moment, the copter sonar set up does not have access to the
raw sonar readings so this code sets the voltage field to zero.
Copter: only send sonar distance to GCS when sonar enabled
AP_NavEKF: Increase gyro bias process noise

This is required to stop the bias estimate from becoming too static
towards the end of longer flights.
AP_NavEKF: Fix bug causing immediate clearing of diverged status on reset
AP_NavEKF: Scale divergence check with covariance

This provides consistent behaviour for a range of gyro bias process
noise settings and automatically adjusts sensitivity as filter learns bias
AP_InertialSensor: fixed example build
AP_GPS: fixed example build
AP_NavEKF: Prevent start-up transients re-tripping divergence test
AP_GPS: work around scheduling issue in example code
HAL_Linux: more generic fix for scheduler issues in example sketches

this ensures drivers can run
Copter: only acceept Guided waypoints in Guided mode

Fix #1068. When receiving guided waypoints do not change to GUIDED mode. This serves as a safety precaution for GCS, since they must switch to guided mode before sending the waypoints.
AP_InertialSensor: fixed example build
AP_NavEKF: Default parameter adjustments

Bring Plane glitch protection thresholds into alignment with copter and
rover
Slight increase in accelerometer bias process noise to prevent bias
estimate divergence into limits (Rover and Plane only as Copter does not
seem respond as well to this change)
effective increase in threshold on divergence test to allow increased
margin for bad GPS velocities
AP_NavEKF: Add protection for accel bias estimation errors

Don't do bias estimation if tilted by more than 60 degrees to prevent scale
factor errors affecting result unnecessarily.
Prevent Kalman gain from having the wrong sign due to numerical errors
associated with small process noise values.
Allow smaller Z accel bias process noise values to be set
Plane: prevent a bad glide slope when first entering auto

we need to ensure that prev_WP_loc is not used as it could be
completely different from current_loc. As a precuation, this also sets
up next_WP_loc so that when the set_next_WP() is first called that
prev_WP_loc is set to current_loc
Rover: much simpler SPEED_TURN_GAIN implementation

as soon as we hit the SPEED_TURN_DIST we lower target speed to the
specified gain
Plane: prepare for release of 3.0.3
AC_WPNav: bug fix for loiter init in Hybrid

AC_PosControl::init_xy_controller() has been added to PosControl and is
called by init_loiter_target.
Hybrid is currently using set_loiter_target function to init the loiter
controller. So we have to call init_xy_controller() by set_loiter_target
function.
What happens otherwise?
In AC_PosControl::update_xy_controller, we update "now" with
now = hal.scheduler->millis();
and, as _last_update_xy_ms has not been updated previously by
init_xy_controller(), we just call init_xy_controller().
So, _dt_xy  will be negative and used anyways in all the functions and
PID called by update_xy_controller.
That will avoid at least _accel_target.x/y to be set to 0 but I'm not
sure for the high values, probably an I_term that is not reset and
reached very high value.
Or maybe a cast error somewhere... no clue at all
AC_WPNav: set_loiter_target uses set_xy_target

Loiter is only a horizontal position controller so it should not set the
z-axis position.
Moved pos_control.set_speed and accel functions so order matches
init_loiter_targets function order
Copter: remove setting Z-axis target in Hybrid

This workaround is no longer required because AC_WPNav's
set_loiter_target call no longer sets the position controller's z-axis
target