Refactor `ControllerDefinition` to be more structured

Why are we squishing every button on every peripheral into a single list, then parsing the player index from them? Keep them separated from init. Same for console buttons.

The console buttons Power/Reset (and maybe the likes of Insert Coin and Toggle Difficulty) also need special-casing in terms of being surfaced in the main menubar under Emulator.

From https://github.com/TASEmulators/BizHawk/issues/4012#issuecomment-3298567288:

As groundwork for a one-click populate keybinds feature, I was thinking it might be good to group the virtual keyboard keys somehow inside the ControllerDefinition object, which cores would set by using a new AddKeyboard(this ControllerDefinition def, string[][] rows) extension method similar to AddXYPair. (I'd choose a list of lists so that maybe it could also be used to eliminate or at least reduce the amount of boilerplate in virtual pad schemata for keyboards.) The keybinds dialog would then show a button if the metadata is present, and clicking the button would read from a new DefaultControls prop (somehow; it's currently instantiated in the Config ctor and then falls out of scope without being stored).

Start by locating ControllerDefinition and tracing how peripheral and console buttons are collected, player indices are parsed, and menu items are surfaced. Review issue #4012's linked comment for the proposed keyboard metadata and DefaultControls lifetime. Done means these controls are structured separately from initialization and the related menu and keybind behavior is addressed.