2.0: generate a library from a standard base plus extension overlays

[ctgnz]

Placeholder for the 2.0.0 architectural change. Likely to become an epic - this records the decisions and
evidence so far rather than a finished design.

The split that drives it

Two concerns have been conflated:

• Model authoring is usefully thought of as a standard model plus extensions producing a superset.
• Consumption is not. A client application sees exactly one library, containing whatever model it was
  generated from, and must have exactly one generated library on its classpath. Two would mean two
  IconLibrary implementations and an ambiguous discovery (Discover the IconLibrary implementation from the classpath instead of naming it #76).

So composition belongs at generation time, and the output stays a single artifact. That rules out the
otherwise-obvious idea of hallux depending on jmsfx-standard and contributing only its additions -
that produces two libraries on the classpath, which is the case #76 has to fail on.

Why it is now feasible

Both preconditions are established and verified:

• The models are a true superset (Bring the hallux model into a true superset of the standard model #74). Keyed by code: 3,423 shared elements, 3,421 identical, 0
  rendering differences, 0 absent from hallux, 0 renames. The only two differences are additive - hallux
  binds amplifierTwoClass/frameAmplifierClass where the standard leaves them unset.
• The fragments are identical (Normalise SVG fragment formatting: strip editor metadata and pretty-print consistently #71). All 2,973 shared fragments are byte-identical across the two
  repos, so the comparison is a cmp rather than a heuristic.

model-hallux.yml is therefore a 3,724-element file of which 3,423 elements are a verbatim copy. An
extension overlay would carry only the 301 additions.

Questions to settle

• Overlay format: additions only, or a delta that can also amend? Additions-only is the stronger
  invariant and matches what hallux actually does today - and CTG has confirmed additive-only is a
  deliberate rule, not an accident of how it turned out.
• Enforcement: a model comparison in the spirit of FragmentComparator, failing the build if an
  overlay ever removes, renames or alters a base element. The comparison already exists as a script and
  would become a proper tool.
• Fragment packaging: the generated library needs every fragment it can draw, including the 2,973 it
  shares with the base. Either they are duplicated into each library's jar at build time, or a
  resources-only artifact carries them. The latter must not implement IconLibrary, or it reintroduces
  the two-libraries problem. Note 2.0: inject SVG fragments into the generated classes instead of resolving file paths #82 may make this moot, by removing fragment files from the equation.
• Repo layout: whether the overlay lives in the hallux repo (as model-hallux.yml does now) or beside
  the base model.

Related

• Discover the IconLibrary implementation from the classpath instead of naming it #76 - discovering the single IconLibrary from the classpath; the consumer-side half of this.
• Run FragmentNormaliser as a build check, so un-normalised fragments cannot land #73 - running the normaliser as a build check, which meets the same jmsfx/hallux coupling question.
• 2.0: inject SVG fragments into the generated classes instead of resolving file paths #82 - injecting fragments into the generated classes, the other half of the 2.0 change.
• hallux's own data model is separately insulated from this: it persists its own enum codes and holds
  jmsfx elements as re-pointable fields, so a restructure here does not migrate hallux data.