Core model architecture refactor / modernization 🎉

[xaviernogueira]

Changes:

• shared.types.Variable is used to represent all constants, state variables, and intermediate calculation "dynamic" variables. These are "registered" to a given model (see TSM module for examples in dynamic_variables.py, state_variables.py, static_variables.py. The Variable.use attribute determines whether it is dynamic, state, or static. This will change how it is treated.
• Model will be inherited by all sub-modules and powers the underlying workflow. One can override the Model.__init__ function for a sub-module (i.e., tsm.model.EnergyBudget.__init__()) as long as super().__init__() is called at the end. With base.Model fully instantiated, all functionality will work!
• A Model instance contains Model.dataset, which is a xarray.Dataset that will act as the main object for a model. On can init a Model instance using a pre-existing dataset via the Model(hotstart_dataset=xr.Dataset(...)) pattern. Upon everytime step, Model.dataset is appended.
• sorter.py handles the sorting of variables into Model.computation_order. This is the order of calculations that will be run on each timestep increment before appending to the pre-existing Model.dataset. The advantage here is that we only have to look at one place to debug a new model, as it will prevent you from even trying to run it if all the variables can't be calculated.
• Module-specific logic that turns on/off some variable or calculation should be triggered in the __init__ function and use Model.register_variable() and/or Model.unregister_variable() as necessary. Using these functions tells the sorter to re-calculate Model.computation_order as needed.

Unfinished work:

• Double-check all the units/descriptions/long names for TSM variables.
• I/we need to figure out how to use xarray.apply_ufunc for non-math computations. For the Reynolds Number calculation, there is if/else logic, that isn't as easily vectorized. Two functions are affected and commented out with a "TODO" comment! TSM will not be functional until this is resolved. (I see one way to do it, but I want to look for a more elegant solution).
• Once the above comment is addressed, we should move our existing TSM tests to test_5_tsm_answers.py.

Advantages:

• base.Model contains all the code that executes a time step. Therefore, we can focus performance tweaks on one location.
• Highly flexible and input resilient - a prior ordering or Variables, or coming up with complicated logic to handle sub-module specific logic (like turning on/off a variable) is made redundant by a sorting function that validates the "computation order". This means that as developers we can focus on writing equations and Variable classes, and not re-invent the wheel for each sub-module. Any module specific logic will be verified before a run if allowed via recalculating Model.computation_order after changes to the registered variables are made.
• Fully tested - I went out of my way to test every attribute and optional pattern I wrote (see coverage stats below).

Test coverage stats:
Test coverage refers to the % of lines of codes triggered by our test suite. To see this, run pytest --cov. This requires an extension that is included in the environment.yml, so if you haven't cloned that environment to that first.

• base.py: 81%
• shared/types.py: 100%
• sorter.py: 96%
• utils.py: 61%