Refactoring the Health Variable Class

[WardLT]

Implements a hierarchical model for the parameters of different storage system models.

Fixes #10 by providing a simpler implementation of the features there (similar to Option 1 of the proposed) and #6 by creating a class which is only for model parameters.

We seem to be drifting towards an solution to #7 where the updatable parameters are kept alongside the model parameters, which I'm OK with thus far. That may change once we introduce some kind of container for "Joint State" which combines the always-updatable model state with sometimes-updatable

To do list:

• [x] Add a "set item by name" method
• [x] Raise errors if users try to update an field is not marked as updatable
• [x] Express a HealthVariable for an ECM with variable numbers of RC elements
• [x] Get all updatable variables
• [x] Get total length of updatable parameters
• [x] Express different models for circuit elements whose properties change with SOC/temperature
• [x] Add TODOs in the codebase indicating where to add a "batch dimension" for when a single HealthVariable instance describes a several parameterizations of the same physical system. Create an Issue describing what behavior we want We'll deal with this later
• [x] Add a new data model for system state and outputs Punting for now, use the GeneralContainer from @victorventuri 's refactor
• [x] Either delete existing "Model" and "UKF" implementations then create an Issue to add them back in, or modify them (if we're successful in this implementation)
• [x] Disallow lists, only allow sequences to be tuples

[victorventuri]

I am jotting down comments here as I read through the code, so maybe by the time I reach the end, some of them will have been resolved and I may forget to iterate back.

1. Based on the make_all_updatable method, the current definition of HealthVariable does not allow for fields to just be lists (or iterables) of floats, for instance; everything inside it must be another HealthVariable it looks like
2. Regarding the TODO on line 68 of base.py, the answer is positively "yes!": when assembling the necessary matrices for updating transient states, we need to know the values of parameters even if they are "immutable"
3. I like the option of making everything updatable recursively (despite somewhat fearing it a bit as well)