Track and Flag extrapolation within subsystem metamodels

Desired capability or behavior.

Aviary currently uses metamodels within subsystems such as Propulsion and Aerodynamics. These models can extrapolate to create data outside of the bounds of the input data for that system.
Examples might include:

1. Mach/Altitude/Throttle point that is outside of all those given in the Engine Deck.
2. Mach/Altitude/CL point outside of the aero prediction tables generated by aviary aero or provided by the user as tabular aero data.

It would be good to flag cases where Aviary extrapolates to the user as it would help the designer understand the validity of the assumptions in the model, and indicate where a higher fidelity physics-based subsystem may be more appropriate. (e.g. run NPSS at a greater range of operating conditions in the sky, or run CFD aero points over a greater range of CLs).

There are 2 levels where extrapolation could be used:

1. At some trajectory point on the path to the optimal solution (this is probably ok)
2. At some trajectory point in the final solution (this might invalidate the solution or at the very least increase the uncertainty for that solution).

For the internal aviary aero (EDET) I believe there are additional levels of extrapolation:

1. Extrapolation could occur within the EDET lookup tables when calculating the aero performance of an aircraft.
2. Extrapolation could occur on continuous functions of empirical relationships if the function is evaluated outside the bounds of the data used to fit that empirical relationship.
   This is also true for all of the empirical relationships in Aviary (e.g. mass subsystem).

User should be alerted to whether extrapolation was used, when in the optimization it was required (optimization path or final solution) along with other useful diagnostic data such as the closest points used for extrapolation, the extrapolation method (e.g. linear) and ideally the fraction of the trajectory that is affected by the extrapolation.

(For a transport aircraft the user probably doesn't care about a few minutes in the middle of descent, but cares a lot about any extrapolation in the cruise phase. Likewise a user evaluating time to climb for a fighter interceptor aircraft would care a lot about extrapolation in the climb segment.)

Diagnostic data could be shown using something similar to OpenMDAOs view_mm analysis feature.
Example here showing that if extrapolation into red circled zone occured then that might be problematic, this could be alongside data showing where in the trajectory the extrapolation occured:

These ideas triggered by discussion with dev team on PR906

Start by reviewing PR906 and OpenMDAO's view_mm analysis feature, then trace how subsystem metamodels and EDET currently handle extrapolation. Define the diagnostic entry points and data needed to distinguish optimization-path from final-solution extrapolation. Done means the scope, reporting behavior, and affected trajectory data are agreed and covered by tests.