[Feature Request] Modifier layer for C-Button and D-pad assignments

### The idea

A held modifier that swaps what every C-Button and D-pad direction is assigned to, so the same buttons carry a second (or third) set of items. This is how console MMOs solve the same problem - FFXIV's cross hotbar holds a trigger to reach another eight actions - and it is the same problem SoH has: far more useful items than buttons to put them on.

**Equip Items on Dpad** already doubled the slots once, from four to eight. A layer multiplies them instead.

### Why ask before building

The plumbing is not the hard part, the agreement is. Some questions worth settling first:

- **Is this wanted at all?** It changes a core interaction, and "hold a button and the HUD changes" is the kind of thing purists and speedrunners have opinions about. Better to hear that now than after the PR.
- **How many layers, and on what input?** A layer modifier is not an N64 button, so it needs a virtual input in the controller config. There is precedent (`BTN_CUSTOM_OCARINA_NOTE_*`, `BTN_CUSTOM_RSTICK_*`), but the choice is a design one.
- **Storage.** `ItemEquips` already carries the SoH comment `Changed from 4 to 8 to support Dpad equips`; another layer is another array of the same shape, mirrored into `childEquips`/`adultEquips` and serialised by SaveManager. Straightforward, but it is savegame surface, so it wants a decision rather than an assumption.
- **Scope of the first pass.** C-Buttons only, one extra layer, no D-pad, would be a much smaller change than the general form, and would prove the interaction before it spreads.

### Reach

Everything that reads `equips.buttonItems` has to learn which layer is live: button alphas and the restriction blocks in `Interface_UpdateButtonsPart1`, HUD icon and ammo drawing, `Player_GetItemOnButton` and `Player_ProcessItemButtons`, the kaleido equip flow and its equipped-item outline, the age swap in and out of `childEquips`/`adultEquips`, and save/load. None of it is difficult; all of it is places to get wrong, and several are in decomp.

### Status

**Nothing is written for this** - unlike #7067, which is already implemented on a branch. I am happy to build it if maintainers would take it, and would rather hear the shape you want first than guess. It also composes with #7067: once a song is an assignable item, extra layers are simply more places to put one.

Start by reviewing ItemEquips, childEquips/adultEquips, and SaveManager to understand the savegame surface. Then trace equips.buttonItems through Interface_UpdateButtonsPart1, HUD drawing, Player_GetItemOnButton, Player_ProcessItemButtons, and the kaleido equip flow. Done requires an agreed layer count, input, and first-pass scope before implementation spans those paths.

Written by the indexing model from the issue text.