Define structural reform and dynamic-variable support across API boundaries

These have become quite a challenge, and I want to outline some issues present here. I think this calls for a design doc and some input from @PavelMakarchuk in terms of his use cases, preferences, etc., as we move forward. Here are the issues I can think of off of the top of my head:

• Structural reforms require creating a new microsimulation on the fly. All metadata generated for the API does not include any new variables introduced as part of the structure, thereby preventing accurate display of household variables for, e.g., the New York WFTC, which creates a new variable.
• We have a longstanding issue when attempting to instantiate a structural reform in any year other than the default year, as the code does not recognize the structural reform's presence.
• The code meant to actually modify the API in order to create the reform feels hackish, redundant, and at times brittle. This code contains a "bypass" value that no other type of variable contains. It requires instantiating these reforms twice, once at one point within the API, and once either at another point in the API or somewhere in -core, I forget which.
• The system we use to create these reforms feels less rigid and systematic than it could be. There isn't a clear "structural reform" interface, and instead we use the standard Reform class from -core, but with consistent modifications (e.g., the "bypass" variable) that require an experienced user to actually build these reforms. I imagine parts of this process could be systematized, modularized, and simplified using a new class that builds on top of -core's Reform class.

I'm sure there are other disadvantages present in the way we work with structural reforms, but they don't come to mind at the moment.

Start with the requested design document and trace how structural reforms are instantiated in the API and in -core, including metadata generation and non-default-year handling. Review the existing Reform class and the bypass value, and collect PavelMakarchuk's use cases and preferences. Done means an agreed design that defines the structural-reform interface and dynamic-variable behavior across API boundaries.