Feature: have the Mission Feasibility Checker check for a takeoff waypoint

[TSC21]

Test data / coverage

1. make px4_sitl_default gazebo_plane
2. Create a mission without a takeoff waypoint - mission check will complain;
3. Create a mission with a takeoff waypoint, but not being the first waypoint item - mission check will complain;
4. Create a mission with a takeoff waypoint not as the first item, but having the previous items not being position related waypoints - mission check will pass;

Describe problem solved by the proposed pull request
This PR addresses #10657.

Describe your preferred solution

1. Adding a check for the MC and FW takeoff on the mission feasibility checker, controlled by a parameter MIS_TAKEOFF_REQ, which allows to verify if there's a takeoff waypoint on the loaded mission;
2. If the takeoff waypoint exists but it's not the first mission item, then a whitelist is applied to the check so to verify if the items previous to the takeoff waypoint items are not waypoint/position related points.
3. Two different critical log messages are used to warn 1. and 2.

Describe possible alternatives
#10657 contains other approaches that may complement this solution.

@Antiheavy, here it goes.

[Antiheavy]

Thanks @TSC21 ! Not only is this a helpful reminder for users, this is an important SAFETY feature too. Requiring the user to upload a mission with a properly ordered Takeoff waypoint help mitigate the following scenario:

Our vehicle is a typical hand-launched fixed wing. We use Launch Detection to protect the motor from spooling up at unexpected times during ground handling. Too often our users will plan a mission using only a Survey Pattern and a Landing Pattern (Landing Pattern use is required since we use RTL_TYPE=1), forgetting they must place a Takeoff Waypoint at the start of the mission. This leads to an unsafe condition where using "Start Mission" in QGC switches to Mission mode and Arms the vehicle and LaunchDetection is by-passed. In this unsafe state LandDetector can easily switch to Flying by wind on the pitot tube or the user handling the vehicle on the ground. This causes the motor to spool up unexpectedly (dangerously) and even if the user manages to hand launch the vehicle, the fixed-wing takeoff logic isn't used, often resulting in a crash.

This PR is an important component to improving safety and ease of use for the above common scenario.

[Antiheavy]

Also, I have tested extensively in SITL based on our specific use case and everything seems to be working properly from the user perspective.

[julianoes]

This looks correct but what I don't understand is if there is actually a difference between the the multicopter and fixedwing case. If not, then that's a lot of duplicated code and should probably go in a separate function.

[TSC21]

This looks correct but what I don't understand is if there is actually a difference between the the multicopter and fixedwing case. If not, then that's a lot of duplicated code and should probably go in a separate function.

@julianoes that's actually a fair point and I don't see a real difference here between them. Maybe we can set a common function for them?

[TSC21]

@julianoes I did a minor cleanup and addressed your concern regarding the repeated code. I think the feasibility checker still needs a major restructure, as some of the logic seems to be repeated and in some cases redundant, but I think we can bring that in a next PR.

[Antiheavy]

I ran SITL on today's commit and everything checks out.

[julianoes]

One change needed, then this is good to go.

[julianoes]

Ok, this can go in!

[julianoes]

I'm ignoring the "Hardware Test" CI, not sure what is wrong with it.

[TSC21]

Thanks @julianoes!