AHRS/VisualOdom/Copter: allow visual odometry to align yaw to GPS-for-yaw

[rmackay9]

This PR (in a roundabout way) allows AP_VisualOdom (aka ExternalNav) to align its yaw to the AHRS's yaw even if the yaw source is GSF or GPS-for-yaw. This resolves the 2nd item in issue #15859

To provide some background, in AP_VisualOdom_IntelT265::align_sensor_to_vehicle() we have the check shown below to protect against re-aligning the external nav system's yaw (e.g. T265) to the AHRS's yaw if the AHRS is using the camera as its source (aka "drinking our own bathwater"). This is important to avoid a slight random shift on each alignment.

// do not align to ahrs if it is using us as its yaw source
if (AP::ahrs().is_ext_nav_used_for_yaw()) {
    return false;
}

The problem is that the AP_AHRS::is_ext_nav_used_for_yaw() returns true (if EKF3 is active) if the yaw source is ExtNav, GSF or GPS-for-yaw meaning AP_VisualOdom can't align to any of these sources.. but it should be able to align to GSF or GPS-for-yaw. This badly named method is renamed to "using_noncompass_for_yaw" and a new "using_extnav_for_yaw" method is added.

This has been tested in SITL using gps-for-yaw and vicon together and below are screenshots showing BEFORE (where the visual odom could not be re-aligned to match gps-for-yaw) and AFTER where it was re-aligned.