[cbrisebois-lasp]

Problem

Every reference to a type loads its own copy of the model. A component
builds a fresh Packed_U16 for each field that uses it, and that copy
loads fresh copies of its own field types. One cold load of the EMA flight
assembly makes 2,399 model loads for 475 distinct files (packed_u16
alone 205 times), holds a tree of duplicates where a shared graph would
do, and writes 1.8 GB to the model cache on the way. That load is what
every assembly-level generator pays, so it sets the cost of a clean build.

Change

Record, enumeration, and array models are marked shareable, and
model_loader.load_model returns the one object it already built for a
shareable file (and load arguments) within the process. These types are
only completed after they load (a record fills in its fields' type ranges
on first request), never altered. Components stay unshared because the
assembly writes instance data into each one it loads, and submodels
because their parent writes itself into them. A load that passes
ignore_cache=True still builds a fresh object, which then becomes the
shared one, so the flag keeps its meaning.

Measured on one cold flight assembly load

	Before	After
Load time	101 s	59 s
Models built	2,399	475
Retained Python memory	267 MB	62 MB
Process peak RSS	1,015 MB	291 MB
Model cache written	1.8 GB	640 MB

Verification

• All 779 generated sources of a clean flight rebuild are byte for byte
  identical to those generated without sharing, apart from the generation
  timestamp line.
• redo/test/shared_models: a record, enumeration, and array are shared;
  ignore_cache builds fresh and replaces; a component is built anew on
  every load.
• gen/test/records suites pass; flake8 clean.

Limitation

Sharing applies on the load path. A component restored from the on-disk
model cache is unpickled with its own embedded copies of its types, so a
warm build keeps those duplicates. Fixing that means pickling with
persistent ids and is a separate change.

[dinkelk]

Seems like an in-memory cache should live with the model cache database so it is transparent. I tried a similar change a few years ago, but rejected it because it did not affect performance much. But if it is more memory efficient, maybe we should reconsider.

I really don't like the "sharable" flag here. Ideally we could remove need for something like that. The tracking overhead on all model types seems brittle and error prone to manage.