2.0: inject SVG fragments into the generated classes instead of resolving file paths

[ctgnz]

Placeholder for the 2.0.0 architectural change. Likely to become an epic.

Today an icon element returns a location - /svg/Appendices/Land/10120100.svg - and the fragment is
loaded from the classpath at render time. The proposal is that it returns the fragment itself, generated
into the class, so IdentificationSymbolIcon composes a symbol from strings it already holds rather than
from resource lookups.

This became feasible once #71 brought the fragments to a clean, consistent, verifiable state.

Audit results

Two things had to be true. Both are, with qualifications that #78/#79/#80 clear.

1. Does an icon element map to one file, or one per StandardIdentityGroup?

Yes, exactly - zero anomalies across the standard model's main icons:

graphicType	files per element	elements
MAIN, MAIN_1, FULL_OCTAGON, FREE_CANVAS	1	1,521
FULL_FRAME	4, one per identity group	70

No element has a stray suffixed variant; no FULL_FRAME is missing a group. Sector-one/two modifiers are
one apiece; amplifiers follow the same 4-per-group rule.

Three categories do not fit and are keyed on more than identity group:

HqtfDummy   /svg/HQTFFD/{groupId}{dimensionId}{id}.svg        group x dimension
Status      /svg/OCA/0{groupId}{frameId}{id}2.svg             group x frame
Frame       /svg/Frames/0_{identity}{frameId}_{status}{c}.svg identity x frame x status x civilian

They are frame furniture rather than icon elements, so whether they are in scope is a design decision.
There is also a fallback in Entity.getGraphicLocation returning a hardcoded 98100000.svg when
graphicLocation is blank - confirm whether that is dead before relying on the rule.

2. Does each file hold a single well-defined content element?

Predominantly yes: main (1,080), mod1 (272), mod2 (163), HQTFFD (218), frame (199), oca (136),
echelon (58), Amplifier (52). Modifiers, Echelon, Engagement, HQTFFD and OCA are 100% single-root.

The exceptions each have an issue:

• Control Measure fragments: separate the drawn content from the construction scaffolding #78 - 545 Control Measure fragments carry #template/#example scaffolding beside #main.
• Frame fragments: give each a single content root #79 - 10 frame fragments have a second unnamed root.
• Give every fragment's content root its canonical id #80 - a few hundred fragments whose content root carries an editor-suffixed id (main_1_, oca_1_,
  mod1_2_) or no group at all (a bare <path> or <text>).
• 10 amplifier templates (ACTIVITY.svg, AIR.svg, ...) are genuinely multi-group by design - one
  group per amplifier field. They are layout templates rather than icons and probably sit outside this.

With those cleared the rule is simply "the element whose id is the category's canonical name".

Questions to settle

• What exactly is injected - the content element's serialised markup, or something more structured?
• Size: roughly 3,000 fragments, ~1.4MB of SVG in jmsfx-standard's resources today. As string
  constants that lands in the class files instead; worth checking against the 64KB limit on a constant
  and on method bytecode, since the larger Control Measure paths are not small.
• What happens to the resource files - do they remain as the authoring source and become a build
  input only? That would also settle the fragment-packaging question in 2.0: generate a library from a standard base plus extension overlays #81.
• Scope - main icons and modifiers only, or frames, status and HQTFFD too.

Related

• 2.0: generate a library from a standard base plus extension overlays #81 - composing the model from base plus overlays, the other half of 2.0.
• Normalise SVG fragment formatting: strip editor metadata and pretty-print consistently #71 - the normalisation that made this feasible; SvgFingerprint is the tool for verifying any
  fragment rewrite this needs.