Allow aspect settings to be determined by variables

[rubensworks]

Closes CyclopsMC/IntegratedTunnels#278

Aspect settings (aspect properties) could only hold static values before.
Every aspect setting now gets an optional variable slot in the aspect settings gui, just like the variable slots that the part offset gui got.
When a variable is present in that slot, its value overrides the statically configured value of that setting.

This is generic over all aspect properties, so add-ons such as IntegratedTunnels get it for free for their settings (channel, slot, exact match, ...).

Gui

• The aspect settings gui gets one variable slot per setting. Since the gui already pages through settings with the < / > buttons, only the slot of the setting that is currently being configured is visible; the gui informs the server which setting is active through AbstractContainerMenu#clickMenuButton.
• An ok/error signal is drawn next to the slot when it holds a variable, with the error (or an explanation that the setting is variable-driven) as tooltip.
• The manual input field is disabled while the setting is driven by a variable.
• The gui and its texture are 24px taller to make room for the slot row.

Behaviour

• Variables are stored in a named inventory per aspect (aspectVariables_<aspect name>) inside the part state, so they are persisted with the part and dropped when the part is broken.
• PartStateAspectVariablesHandler evaluates them on each part update tick and reloads a slot when its variable is invalidated, mirroring PartStateOffsetHandler.
• The statically configured value is left untouched, and remains the fallback when the slot is empty, the variable errors, its value type does not match the setting, or the value does not pass the setting's validator.

API

All additive, with defaults, so existing implementations keep working:

• IAspect#getStaticProperties: the configured properties without variable-driven overrides. IAspect#getProperties now returns the variable-driven values where present.
• IPartState#updateAspectVariables, #markAspectVariablesChanged, #markAspectPropertiesChanged, #getAspectVariableError, #getAspectPropertiesVariableDriven
• IPartType#onAspectVariablesChanged
• IPartState#loadInventoryNamed now bounds-checks against the target inventory size, so a shrunken property list can not cause an out-of-bounds crash.

Tests

New GameTestsAspectVariables covers:

• the default and statically configured value being used when no variable is present,
• a constant variable overriding the static value, without modifying it,
• a variable whose value changes over time being picked up,
• removing a variable falling back to the static value,
• a wrong value type and a value rejected by the setting's validator both producing an error and falling back to the static value,
• a variable-driven setting on a writer aspect (redstone pulse emit value),
• a variable that is resolved through the network (variable store) instead of a constant,
• the variables surviving a part state serialization round-trip,
• the variables being dropped when the part is broken,
• the aspect settings container storing the variable in the part state, and only exposing/accepting the slot of the active setting.

./gradlew build and ./gradlew runGameTestServer (907 tests) pass.

Note on an existing test helper

GameTestHelpersIntegratedDynamics#setAspectProperty mutated the aspect's shared default properties object whenever a part had no properties stored yet, which leaked configuration across game tests. It now clones instead. Two redstone pulse tests relied on that leak and set their pulse length on the wrong part/aspect; they now set it on the writer part itself.

---

Generated by Claude Code

[coveralls]

coverage: 46.168% (+0.7%) from 45.511% — claude/aspect-settings-variable-slots-fdjwp3 into master-1.21-lts