User input handling overhaul

Desired capability or behavior.

There is a need for a significant refactor of the entire chain of code for handling user inputs. This starts with fortran-to-aviary, then create_vehicle, and finally the preprocessors.

At a very high level, this is the necessary delineation of "tasks" that each step should do:

1. fortran-to-aviary
   This code should only make changes to input files that have to be done because FLOPS or GASP treats inputs differently than Aviary does. Examples of this include variables with "split behavior" (like mass variables either being scalers or overrides depending on value) and variables whose defaults change based on other provided inputs (Aviary does [or at least should] not do this - it only pulls a singular default from metadata).
2. create_vehicle()
   This function needs to be completely overhauled and possibly replaced with a series of separate functions. First, the input file should be read in without any modifications of any kind. Second, a initial guessing function needs to be created - this step probably needs to get moved to after the preprocessing step. The initial guessing step is going to be different that the GASP "initialization guessing" step - that should probably be completely replaced by this new function using our own judgement on calculation. Guesses that are tied to a particular flight phase should be computed somewhere specific to that phase (such as its builder) instead of in this "global" initial guessing step.
3. preprocessors
   The preprocessors should only make changes that make sense to a pure Aviary problem - any FLOPS or GASP specific behavior should NOT be here!! Think about the preprocessor tasks in the context of being applied to an Aviary file made from scratch - we should be thinking "is this how we'd like Aviary to behave?" and NOT "we need to replicate how FLOPS and GASP were manipulating values" - that is the job of fortran_to_aviary!!. Any preprocessor tasks that are specific to a certain subsystem and/or method need to be clearly separated into their own section. For example, if there are a bunch of things that need to be done for FLOPS aero, they need to be all gathered in a single place. In the future I plan to provide SubsystemBuilders with the ability to preprocess inputs, and will be offloading these method-specific steps there.

To perform the refactor, I recommend we work backwards starting with the preprocessors to determine what behaviors we want to have in Aviary, followed by moving parts of create_vehicle() to their appropriate location, and finally a fortran_to_aviary refactor that incorporates any moved behaviors from the previous steps.

Suggested implementation.

No response

Start with the preprocessors and trace how inputs from a pure Aviary problem are transformed, then follow the flow through create_vehicle() and fortran-to-aviary. Identify which behaviors belong to Aviary, FLOPS/GASP conversion, initial guessing, or phase-specific builders. Done means the responsibilities are separated as described and each step no longer performs work assigned to another layer.