Consider intermediate DFN schema v1.1 not v2

[wpbonelli]

Continuing along the lines of #251, which moved new DFN schema work to a separate dfn branch, and #233, which (now in the context of that branch, not the mainline) distinguished the format change (DFN -> TOML) from the schema change (v1 -> v2)...

Thanks to my inadequate advance planning of all this, the mainline is now in a strange state where Dfn.load_all() accepts version=1 (text DFN) or version=2 (TOML). As described in #233 this conflates format with schema. It also isn't really right to think of the updated schema as it now exists on the mainline as a breaking v2, it's more like a cleaned-up v1 with some data normalization (omitting null/empty fields) and a few structural changes.

I'm thinking we should introduce the format/schema distinction on the mainline, call the "new" schema as it exists on the mainline v1.1 instead of v2, and reserve v2 (to be released with devtools 2.x) for the full schema redesign which flopy 4.x and eventually mf6 will consume.

As I've made a proper mess of things in the mainline/releases (1.7.0+) already, we may have to accept some "breaking" changes in this DFN machinery in the devtools 1.x series. Besides @martclanor I think we are the only ones consuming it (just in flopy codegen) right now, luckily.

[aprovost-usgs]

Agree that major schema redesigns should be considered primary, and schema tweaks and new formats should be considered secondary. My two cents - seems like the benefit of clarity and consistency on that going forward would outweigh the inconvenience of the breaking change, which is unlikely to cause widespread misery at this point.

[wpbonelli]

thanks @aprovost-usgs will proceed with this plan then.

[wpbonelli]

described approach in planning doc in #269