Separate structural from format spec #246
Description
The current DFNs carry 2 general kinds of information: structural and input format.
Structural info is e.g. what are the components of a simulation, how are they related, what variables are in each. Ideally this should be presented in a canonical form, whatever we decide that means (for instance, define things in terms of variables living on features of the grid, or aligned to a time dimension, etc, instead of in terms of artificial dimensions like maxbound).
Input format info is e.g. what are the various ways MF6 lets you provide arrays (sparse list as in period data, full grid array, layer array), when extra keywords like FILEIN/FILEOUT are necessary, etc.
These are separate concerns. Generated classes should just encode the structure and data model, for instance, and only the IO layer should know about input formats. cf #241 and #231 (comment)
@mjreno suggested composing formatting details as a separate body of specification on top of the canonical component/data model, the former of which consumers could choose whether or not to pay attention to.
This can be made rigorous via some system like JSON Schema as suggested by @mwtoews here.
Some work in devtools has begun on a new DFN schema, (now proceeding on a dedicated branch instead of the mainline, but it is still really rough, and it simply loses some of the formatting info instead of separating it. Devtools should lean on python-jsonschema where possible. Flopy3 is already generating its mf6 module from a very early version of the new schema, which was perhaps ill-advised (it should probably have continued to assume the stable legacy DFNs), but it will work so long as the dfn module in the develop branch of devtools is kept stable.