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, and shows the value that its variable currently produces, refreshed continuously, so that players can inspect what a variable evaluates to.
• The aspect properties tooltip of the part gui (added in Show modified aspect property values in tooltip #1706) now also shows variable-driven values, refreshed continuously. Values that are driven by a variable are always listed there, even when they happen to equal the default, since they can change at any moment.
• 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, #getAspectVariableValue, #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.
• ContainerMultipartAspects#getModifiedAspectPropertyValues became public.

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,
• variable-driven settings on the redstone writer: strong power true (a wire on top of a solid block only lights up under strong power), strong power false, a variable-driven pulse length, a variable-driven pulse emit value, and strong power driven by a redstone clock so that it keeps toggling,
• 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,
• the value shown in the aspect settings gui following its variable (including a dynamically changing one) and falling back to the static value after removal,
• the part gui properties tooltip showing the variable-driven value, and showing it even when it equals the default.

./gradlew build and ./gradlew runGameTestServer (916 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.799% (+1.3%) from 45.463% — claude/aspect-settings-variable-slots-fdjwp3 into master-1.21-lts