add ability to have a myna case without an AM build database

[gknapp1]

Cherry-picked from #133.

Allows for Myna cases consisting solely of base class Component steps to be used and not require a database, for example the single-track calibration app implemented in #133.

This means that the apps' parameters for the configure, execute, and/or postprocess functions will likely accept some sort of user input to modify their behavior. In the single-track calibration app, the main parameter is a path to a specific data file containing data to use for calibration.

Practically, this is useful when the input to a specific app is custom-defined and not directly related to AM build data. The Myna database classes contain functions for parsing multiple files (Peregrine, Pelican) or more complex data structures (PeregrineHDF5) representing AM build data. If a Myna app needs other information, like the single-track cross-section data needed by the calibration app, then there may not be good representations of that data in all database types. Consequentially, this can enable mixtures of build data and non-build data in a simulation pipeline (though issue #8 would affect how usable this is), e.g.:

-> single-track calibration (non-build data)
  |-> melt pool simulation (build data, for multiple parts, using single-track calibration results)
     |-> microstructure simulation (build data, for multiple parts)

[streeve]

This is a reasonable solution, but it seems just as easy to allow None to be returned (potentially only error if the user gave a build/part intending to find a DB vs omitting it entirely indicating it's not necessary). But that would mostly just let you skip this new boilerplate code for a custom None

[gknapp1]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces the capability to run Myna cases without an AM build database, which is a valuable addition for applications like calibration. The approach of using a NoDatabase null object and safe dictionary access with nested_get is sound. My review includes one high-severity suggestion to make the NoDatabase implementation more robust by fully implementing the Database interface, which will prevent potential runtime errors.

[streeve]

Last suggestion; not blocking merge