Add custom loadout groups

[truemogician]

Additions

• Custom loadout groups: player-defined, reusable loadout generics built from selected items, usable as a loadout slot just like a built-in generic.
• Groups can nest other generics and custom groups, with cycle detection.
• A new Custom Groups tab in Manage Loadouts holds the whole feature: create, edit, copy, export, and delete groups, plus load a group from file.
• In-editor member list with drag-to-reorder (items and nested groups in one interleaved order) and live Mass/Bulk readouts.
• Export / import groups to standalone files (reuses the existing loadout save/load file dialogs, loadoutgroup storage type).
• Per-save storage, groups are scribed into the save.
• Multiplayer support: group create/edit/delete are synced; a group used as a loadout slot already syncs as a normal generic def.
• Utility_ReferenceGraph: a small generic lazy-edge cycle-detection helper (IsReachable / WouldCreateCycle), reused by group nesting.
• New UI/Icons/export icon.

Changes

• LoadoutGenericDef: _lambda made protected, added a stat-cache invalidation hook and an empty-members guard in updateVars, so the predicate can be driven by a subclass. No change to built-in generics' behavior.
• LoadoutManager.ExposeData now scribes custom groups before the loadouts, so group defs are registered in time for loadout slots to resolve them by defName.

References

• Contributes towards Loadout System Improvements #4625
• Helps with [Discussion]: Allow (any weapon) as option in loadout #3876

Reasoning

• Defining reusable item families is a large ergonomic gap in CE loadouts; custom groups fill it without touching rearm/drop logic.
• A group is a LoadoutGenericDef subclass, so loadout slot save/load and JobGiver_UpdateLoadout work unchanged — a group is a generic.
• Stored per-save so groups travel with the save, which is also what makes multiplayer sync possible.

Alternatives

• Global config file for groups: rejected — hard to be synced in multiplayer.

Testing

• Compiles without warnings (net48, warnings-as-errors)
• Game runs without errors
• Playtested in my own save with more than 300 active mods for several hours

[github-actions]

You can download the rebuilt assembly for this PR here: https://combatextended.lp-programming.com/CombatExtended-27819212851.zip

[github-actions]

You can download the rebuilt assembly for this PR here: https://combatextended.lp-programming.com/CombatExtended-27823707303.zip

[truemogician]

Here's what the custom loadout groups look like in the loadout UI:

Custom group selection for loadout:

Custom group edit / creation:

[github-actions]

You can download the rebuilt assembly for this PR here: https://combatextended.lp-programming.com/CombatExtended-27825072002.zip

[github-actions]

You can download the rebuilt assembly for this PR here: https://combatextended.lp-programming.com/CombatExtended-27850223808.zip

[github-actions]

You can download the rebuilt assembly for this PR here: https://combatextended.lp-programming.com/CombatExtended-27850593372.zip

[Safairette]

Defs are not an appropriate medium to store this kind of custom player-created data, for various compatibility reasons.

[Safairette]

You should not be using defs to store this data, as they were never meant for temporary player-created content in game. They should be stored independently and only merged into the defined generic defs when building the loadout options.

If you need a pointer to how the base game handles custom player-created content like that, you should look at how the custom scenarios and xenotypes are created.