Add axes top level key to configuration format

[TimothyWillard]

Added the concept of 'axes' to represent a single dimension for something that has shape. Axes can take the form of categorical like 'unvaccinated' and 'vaccinated' or 'low', 'medium', 'high' as well as numerical forms like ages being represented by integers or physical space being represented by a continuous (by discretized) axis. This provides a foundation for further structuring parameters and systems by giving them shape.

• Added axes attribute to the ConfigurationModel class to contain a mapping of named axes that can be used throughout a configuration file.
• Added CategoricalAxisModel, IntegerAxisModel, and ContinuousAxisModel classes to represent the three different kinds of axis provided by flepimop2. These classes represent the configuration form of these axes objects, including pydantic based validations.
• Added an Axis class to represent a realized Axis object that can be handed off to parameters, systems, etc. This provides a unified interface for those modules to create objects of appropriate size.

Heavily inspired by work from @MacdonaldJoshuaCaleb on ACCIDDA/op_system. Closes #147.

[pearsonca]

I think we want something like this capability, but I'm not sure what that capability should look like because I'm uncertain of how we plan to use it.

I'm basically thinking of axes as:

• something a system can advertise about itself
• which parameters can be functions of (where the notion of parameter here is more expansive than value / distribution)
• which engines can adjust their operations on
• which observations / transformations can summarize along

What else do they get used for? When are they necessary (vs convenient)?

Can we get some concept documentation now? As "imagine your model is an ODE, then axes mean this, get expressed like this. Translate that model to a PDE, the axes mean this. An ABM, the axes mean ..."

@MacdonaldJoshuaCaleb need your perspective here as well