Payload-Range capabilities need updating

[argonaut22]

Updated after rediscovering the outputs.jl PayloadRange():

steps to bring the function to best practices:

• create new tests to ensure fixes for future PRs
• Update plotting to use Plots.jl (done in branch: argonaut22/plot_redux)
• can we do better* than try-catching any error that gets thrown? the effect with this handling is that any breaking gets hidden and a 0-range diagram is produced with little indication of what went wrong.

With PayloadRange(), we can probably delete example_PRD.jl and PRD_input.toml. If we somehow wanted to keep it, the following would need to be done, since it's currently broken:

• update PRD_input.toml to match the new max_pax nomenclature, and aircraft_type field
• why does the PRD toml example specify 5 missions?

*we should do better 😬

[argonaut22]

Update! found the version in outputs.jl. adjusted tasks accordingly

[ngomezve]

I'll fix this in my PR for off-design missions. The PayloadRange() function is quite outdated and requires some specific aircraft objects (e.g., it cannot have just one mission).

[argonaut22]

Fun new issue: running PayloadRange on an aircraft with only one mission does not work (tries to set ac.parm[imRange,2] when ac.parm is only a Vector). Can replicate with the example_cryo.jl model.

[argonaut22]

After discussing with @askprash , best path forward seems to be to add some code to the start of PayloadRange() to:

• copy/unpack_ac the requested aircraft into a new one with two missions: the design one, and a dummy one
• the dummy mission will be edited by the payload-range study/fxn and exercised with fly_off_design()

This approach addresses the above bug, ensures that the original aircraft does not get accidentally edited, and prevents having to add/remove a mission from an extant model (a convenience that we may want to provide, but def not a priority).

[ngomezve]

PR #119 brings back the dummy mission that copies the design mission. I added this feature in PR #109 but was accidentally removed in PR #114.