Putting the ingress point directly on one end of the FLOT means that AI
flights won't start searching and engaging targets until they reach that
point. If the front line has advanced toward the flight's departure
airfield, it might overfly targets on its way to the IP.
Instead, place an IP for CAS the same way we place any other IP. The AI
will fly to that and start searching from there.
This also:
* Removes the midpoint waypoint, since it didn't serve any real purpose
* Names the FLOT boundary waypoints for what they actually are
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2231.
The next step in splitting up the layout and scheduling phases. This
facilitates splitting flights into two classes where one has a full
flight plan, but one used in the earlier phases of planning has only a
layout. Layout-only flights won't need TOTs, which will make them much
easier to work with once we've migrated TOTs from timedeltas to
datetimes.
Layout-only flights of course aren't actually usable, but it lets us
avoid dealing with the current sim time until we're certain the Flight
will even survive planning.
I'm not actually sure if we'll be able to split the two phases any more,
but this ends up being a nice cleanup anyway.
During package planning we don't care about the details of the flight
plan, just the layout (to check if the layout is threatened and we need
escorts). Splitting these will allow us to reduce the amount of work
that must be done in each loop of the planning phase, potentially
caching attempted flight plans between loops.
Split the oversized file into one per plan type. This also moves the
layout responsibility out of the oversized FlightPlanBuilder and into
each flight plan type file.
