Output products could get "stuck" in an unexpected partially complete state when certain configured product paths are wrong

[Lagejohn]

Because of the way MMTC's output products are written, it's possible for some products to be updated after a run when a bad/nonexistent path in the config (such as raw telemetry table) causes MMTC to abort before everything has been updated. This can result in a state where SCLK kernels and SCLKSCET files have been written but the run history file was never updated, meaning details of the run were never recorded and the run can't be rolled back. This is particularly confusing for users of the web UI as it appears that nothing was written in the "preview" view but upon refresh, the predicted correlation data become actual despite no evidence of new runs in the history widget.

note second correlation carat under the graph along with adjusted error graph, but no run IDs listed in the lower history widget (still erroneously says "initial state")

Instead, MMTC should probably be adjusted to handle this sort of misconfiguration in one of two ways:

1. The bad path is checked and caught before we try to commit and either prevents a preview from being generated or grays out/disables the commit button (along with an error somewhere explaining why it can't commit)
2. Completes and updates all the output products it can (most importantly run history file so i can roll back if the user wants to fix and try again) but throws an error/warning that it couldn't update the relevant product. Ostensibly this would require special handling in the run history file update to account for the nonexistent product that it wasn't able to update.

The first is likely an easier/safer solution as it doesn't have to account for cases where critical output products (such as SCLK kernels) can't be written vs. non-critical products (like the raw TLM table), but will involve upfront validation of all relevant output products and/or their output paths before anything is written.