AP_NavEKF3: accept set origin even when using GPS

[rmackay9]

This removes two unnecessary constraints on when the EKF origin can be set and adds an autotest (courtesy of PeterB).

The existing constraints cause problems when the vehicle is simultaneously using GPS and OpticalFlow (e.g. EK3_SRC1_POSXY = 3/GPS, EK3_SRC1_VELXY=5/OptFlow, EK3_SRC_OPTIONS = 1/FuseAllVelocities) and the vehicle's start location is indoors where there is no GPS. In this situation the user is currently stuck because the constraint means the origin must come from the GPS but the GPS cannot provide a Location. I've received two reports of this inconvenience (the most recent report is here).

Note that I've also removed a constraint for, "PV_AidingMode == AID_ABSOLUTE". As far as I know there is no way the EKF can be in AID_ABSOLUTE without an origin which we check for moments later in setOrigin(). It does no harm but it also does no good and is probably just a left-over from the earlier changes related to a common origin or the moving internal origin.

I have tested this in SITL to confirm that it resolves the issue. Using master/latest with both GPS and optical flow enabled and SIM_GPS_DISABLE=1 the EKF origin could not be set using MAVProxy's right-mouse-button menu.

With this PR the origin could be set.

In addition the vehicle could be force armed (to bypass the "GPS 1: Bad fix" message) and flown. Below is a screen shot of a test in which the GPS was disabled and the EKF origin was purposely set 100m off from the correct Location. The vehicle was armed and flew correctly albeit with a persistent position offset.

When GPS was restored (e.g. param SIM_GPS_DISABLE 0) the vehicle correctly (and smoothly) jumped back to its actual position).

Note that I found a bug in master during testing. This PR makes it no better but also no worse.

[peterbarker]

This sanity check was in place in case the user managed to se origin a very long way away from where the vehicle actually was.

We believe that that isn't a problem post-Extreme ArduPilot moving-origin stuff.

What testing have you done for the case which Extreme ArduPilot thinks it fixed?

I've created this PR which was my attempt at testing this scenario: #27084 in my branch equivalent to this one.

[peterbarker]

... in fact, here's my pre-existing PR: #25110

Note tridge's objection on my PR which would also seem to be the same objection on your PR here (you're also not modifying the function tridge pointed to)