standalone model configuration file with model, approximation, solution, and simulation parameters

[sbenthall]

The goal of this PR is to implement a working example of a HARK configuration file, in Python, as per #857. (Note the ticket originates from 2020).

Such a configuration should include information:

• about "true" model dynamics (stages, blocks,etc.), in
• approximations adopted for computational reasons
• instructions about how to solve the model
• parameters for simulating the model (with the given solution)

While this is functionality that's similar to the HARK 0.x models, this PR aims to implement model configuration subject to several constraints:

• There's a single source of truth for any information about the model's structural equations
• The configuration is a data structure, not a program, in the sense that it relies only on basic data types without cross-referencing between sections. This requirement is there because the next step after this PR is to implement a parser that will transform a YAML file into this kind of configuration object.
• As much as possible, it actually operates with other not-model-specific components in HARK.

This work is informed by work in late 2023 on the HARK 2.0 model specification language.

Some tricky parts remaining to implement include:

• Constructing shocks using mathematical expressions for input parameters from configuration objects DONE
• Settling on a syntax for aspects of the configuration which are really more like 'workflows' than like model details

• n/a Tests for new functionality/models or Tests to reproduce the bug-fix in code.
• [ ] Updated documentation of features that add new functionality.
• [ ] Update CHANGELOG.md with major/minor changes.

[sbenthall]

This PR builds on #1427 which should be merged first.

[sbenthall]

This is now ready for review again.

Since it is mainly about notation, not functionality, there are no new tests to be added. A next step is to implement a solver that uses the algorithm in #1438 on the multi-stage problem defined here, with the given approximations.

The API for this solution algorithm is going to be the main constraint on what the workflow syntax looks like.

I'll be happy to write up some documentation for this, but it probably should get eyeballs and an OK from somebody else on the team, before expending effort on those docs.