[Feature] Refactor HotkeyMenu

HotkeyMenu offers a single input field for each binding that can detect supported inputs. It also uses rudimentary paging to display more hotkey binding GUI elements than can fit on the screen at once, and the ability to remove binds and add multiple binds to a control via right- and middle-mouse clicks.

While this has been functional, it severely limits how hotkey controls can be improved to accomodate features added since the hotkey menu was first implemented, like:

• clearing binds from a control
• adding multiple binds to a control on devices that lack mice (touchscreen + keyboard), right mouse buttons (non-mouse pointers reporting as HID mice), or middle mouse buttons (many laptop touchpads)
• identifying or restricting bind types as being intended for specific input types

Generally well-supported input types include mice, keyboard presses, joysticks, and gamepad/game controllers. But inputs can also include arbitrary types supporting the same devices in different ways:

• absolute axes reporting values between -1 and 1 (0 deadzone)
• axes reporting values betwen 0 and 1 (extremity deadzones and jitter tolerance; many A2D pots in particular, and some throttles and gamepad triggers)
• relative axes for mice or joysticks (value accumulation instead of absolute value; rotational controls, mouse/joystick camera)
• sustained digital buttons (joystick/controller buttons, press-and-hold keyboard inputs)
• stepwise digital controls (onUp- or onDown-only keyboard inputs, digital encoders with variable steps per detent)
• axis-based stepwise controls (mouse wheels, some throttles with detents, activation thresholds for joystick triggers that report as axes)

Some controls designate axis inputs by affixing (joystick) to their labels, which is ambiguous (not all axis inputs are joysticks) and redundant (many of these inputs have stepwise or sustained equivalents of the same name and function).

A refactored HotkeyMenu should:

• Scroll vertically using the same UI standards as the rest of the EE UI
• Display one row per keybind
  
• Display all keybind groups in one column, with the selector scrolling the list to specific groups
• Allow filtering keybinds by name via text entry
• Use the additional space per row to accurately describe both the control and the keybinds, without ambiguous abbreviations
• Provide separate input bind fields for keyboard, joystick/gamepad, mouse, and arbitrary SDL2-supported inputs
• Provide dedicated UI controls to clear or overload each bind field, in addition to existing mouse button controls

Controlling per-bind sensitivity on HotkeyMenu is out of this scope and part of #2770.

Start by locating the existing HotkeyMenu implementation and compare it with other EmptyEpsilon screens for vertical scrolling and group selection patterns. Trace how bind groups and input fields are populated, then use the listed layout, filtering, input-type, clear, and overload requirements as the completion checklist. Per #2770, sensitivity controls are out of scope.