Plane:mode AUTOLAND enhancements

[Hwurzburg]

This PR enhances the new AUTOLAND mode. It adds the following new features:

1. Allows takeoff direction capture, and hence autoland direction and use, in ACRO, STABILIZE, FBWA, TRAINING, and MANUAL modes, in addition to Mode TAKEOFF and AUTO NAV_TAKEOFF, using the same criteria as currently used, the first time after arming.

2. Adds an AUTOLAND_OPTIONS option that will set this direction upon arming using a compass, if in use, instead of ground course, allowing the user to set it on the ground arbitrarily as desired, independent of the actual takeoff direction. The option is in the autoland module for future expansion

3. the "base" leg is actually a WP_LOITER_RAD loiter to alt with tangent exit directly into the final approach waypoint and landing with proper loiter direction.

changes to current behavior, besides the new features, is that once the direction is captured it persists until a disarm occurs. Therefore multiple auto takeoffs while armed no longer reset the direction captured by the first, on each subsequent takeoff. Originally, I thought this behavior was desirable, but I now believe it's not of much benefit and the new behavior avoids the current corner case issue of resetting the direction while in flight if a NAV_TAKEOFF autotakeoff is interrupted and then resumed. Also, this is not available for QudPlanes, even if fixed wing landing option is used. We thought the possibility of getting the direction inappropriately wrong on transitions from a VTOL takeoff just too complex to get correct.

In addition, it removes the AUTOLAND code segments in the commands_logic and mode_takeoff modules, reducing the flash impact overall...

These changes have been tested in SITL and flight-tested in all configurations I could think of.

[Hwurzburg]

Added loiter to alt with direct exit to landing final and moved option to AUTOLAND module...

[IamPete1]

@Hwurzburg @tridge I have done a PR to address the issues with loiter radius scaling, it does get quite bad at higher altitudes.

Hwurzburg#5

In that messing about I have found two other issues. The first is pre-existing and that is what happens if you have LAND_TYPE set to deep stall rather than glide slope. I guess no one has tested? Maybe it is not too bad, but we should either test it or refuse mode entry if the not glide slope. I'm not sure the base entry setup thing makes any sense for it in any case. The other issue is that this re-uses some functions from missions, for example this uses plane.start_command to run the waypoints. This is a issue because of this:

ardupilot/ArduPlane/commands_logic.cpp

Lines 29 to 37 in 230f824

	AP_Mission::Mission_Command next_nav_cmd;
	const uint16_t next_index = mission.get_current_nav_index() + 1;
	const bool have_next_cmd = mission.get_next_nav_cmd(next_index, next_nav_cmd);
	auto_state.wp_is_land_approach = have_next_cmd && (next_nav_cmd.id == MAV_CMD_NAV_LAND);
	#if HAL_QUADPLANE_ENABLED
	if (have_next_cmd && quadplane.is_vtol_land(next_nav_cmd.id)) {
	auto_state.wp_is_land_approach = false;
	}
	#endif

Its looking in the mission at what the next command is, of course here were not in the mission so that will be nonsense. Maybe it would be enough to warp a check that were in auto for that bit. In the longer term it would be nice to rework more comprehensively so both mission and this could use a common base method.

[Hwurzburg]

Added all of Pete Hall's changes to cope with high altitude

peter is happy on dev call