Add .rmgr replay file recording

[hopskipnfall]

Note: This is a giant PR and I would normally split this up to make it easier
to review, but then GitHub wouldn't build the binaries for us.

The important file to read is docs/RMGR_SPEC.md.
All of the code is based on the decisions in that document. This PR
description also gives background on aspects of the implementation.
Consider this PR just a review of that SPEC document.

Summary

Adds an optional, per-match replay recording feature: while a Smash Remix
match is in progress, RMG-K can record every seated port's controller
inputs and (for Smash Remix specifically) a snapshot of game state -
position, damage, stocks, action state, items, stage hazards, match
settings (including RNG seed and Remix's own gameplay/stage mutators) - to
a self-contained binary file (.rmgr), independent of and unrelated to
the existing Kaillera .krec recording. The intent is to support
downstream analysis tooling (e.g. the companion web viewer,
rmgr-viewer) without
needing to re-run the emulator to reconstruct what happened in a match.

The feature is fully optional at both build time and runtime:

• Build time: gated behind a new GAME_STATS CMake option (on by
  default; ./Build.sh --no-game-stats or -DGAME_STATS=OFF disables it).
  It requires building mupen64plus-core with DEBUGGER=1, which pulls in
  a binutils (libopcodes/libbfd) link dependency - the only new
  external dependency this feature introduces.
• Runtime: off by default. A "Record replay file (.rmgr) by default"
  checkbox in Settings controls the default; per-session overrides exist
  for netplay/playback dialogs and headless export tooling.

The format is currently at version 5 (docs/RMGR_SPEC.md §title) -
several incompatible revisions happened during development before this
spec document existed to pin the layout down; there is no migration path
from anything recorded before this document, and none is planned. Since
this document was written, the container format itself hasn't changed
again, but MatchSettings/StateFrame/ItemUpdate's own
recorderSchemaVersion (scoped to goodName == "SmashRemix2.0.1") has:

• Schema 2 added render scale (fighters and items), a
  character-specific state field, shield health, and a special-hit-status
  byte to StateFrame/ItemUpdate - see §5.2/§5.3 of the spec.
• Schema 3 added an RNG seed (sSYUtilsRandomSeed, captured once at
  match start - sufficient for deterministic replay-from-inputs, since
  loading it and replaying this match's recorded controller inputs
  reproduces the same RNG-dependent outcomes) and all 31 Gameplay Settings
  plus 8 (core) Stage Settings from Remix's own Toggles.asm mutators
  (hitstun, hitlag, DI, Z-cancel, rage, tripping, game speed, hazard mode,
  camera mode, and so on) to MatchSettings - see §5.1/§5.1.1/§5.1.2.

Design

The on-disk format is fully specified in
docs/RMGR_SPEC.md (added by this PR) - that document
is the source of truth for the byte layout; this section is a summary of
the design decisions behind it.

Self-describing binary event stream, modeled on
Project Slippi's .slp format for
Melee (not byte-compatible, several deliberate departures - see the spec's
§1). A small fixed header is followed by a sequence of typed events, each
a 1-byte command code plus a payload whose size was declared up front by
the very first event in the stream. A reader that doesn't recognize a
command code can still skip it correctly using that declared size, so the
format can grow new event types or new trailing fields on existing events
without breaking old parsers.

Buffered, then compressed once. The recorder holds the whole match's
events in memory as it plays and writes the file in a single pass -
header, then a deflate-compressed event-stream block - only once the
match ends. A crash or force-quit mid-match produces no file at all (an
accepted trade-off - the format has no partial/truncated-file case to
reason about). This keeps files small: per-frame data is highly
redundant frame-to-frame, and compressing the whole stream captures that
well without any bespoke encoding. In practice, across 157 real matches
recorded during development on the current format version: ~2.2 KB per
second of match (median and mean agree closely; ~2.0-4.0 KB/s range
depending on how much is happening on screen) - a typical ~2-minute match
is roughly 260 KB.

Two-layer event catalog, so the format isn't Smash-specific at the
container level:

• A core layer (player names, port slot types, controller inputs,
  match end/frame count) that's always recorded for any N64 title RMG-K
  can drive - conceptually close to a .krec-equivalent recording on its
  own.
• A smash64 game-family extension layer (match settings, per-frame
  position/damage/stocks/action-state, items, stage hazards, final
  placements) that's only recorded when the loaded ROM is a recognized
  build (goodName == "SmashRemix2.0.1" today). The header's new
  gameFamily field tells a reader which extension events, if any, apply
  • a reader checks that one field instead of maintaining its own list of
    every goodName string that's ever meant "this is Smash."

This means a future second game (or a different Smash Remix/vanilla SSB64
build) can define its own extension layer without touching this one, and
(once a game-agnostic recording trigger is wired up - see Known
limitations below) an unrecognized game still produces a valid,
input-only recording rather than nothing at all.

goodName/gameFamily/recorderSchemaVersion as three independent
axes (spec §3.2): gameFamily says which extension events apply,
goodName pins the exact ROM build, and recorderSchemaVersion is a
per-goodName counter bumped whenever this recorder's understanding of
that build's memory layout changes - independent of the container
format's own version, and independent of gameFamily. This is the
mechanism schema 2 and schema 3 (above) both used, rather than bumping the
container version.

Architecture

• Source/RMG-Core/Replay.cpp/.hpp - the writer and its small public
  API (OnEmulationStart/OnFrame/OnEmulationStop, plus per-session
  overrides for output path/player names/timestamp used by headless
  export). Internally: a per-match state machine (Idle /
  WaitingForMatch / Recording), an in-memory event buffer, and a
  detached worker thread for the match-end compress-and-write step so
  stopping emulation (frequently on the UI thread, via
  CoreStopEmulation()) never blocks on it.
• Source/RMG-Core/ReplayMemory.cpp/.hpp - the Smash Remix
  RDRAM pointer-chase that feeds the writer; not part of the container
  format itself, the source of truth for every extension field's
  semantics. Fully separate from the writer so a future second game family
  doesn't need to touch this file.
• Source/RMG/Utilities/KailleraExport/ - headless .krec → .rmgr
  export tooling (ReplayFileExport.*, ReplayHook.*), for backfilling
  recordings from existing Kaillera netplay recordings without replaying
  them interactively.
• Settings/UI - a new GameStats_ReplayEnabled setting and its
  checkbox in SettingsDialog; per-dialog override plumbing in the
  Kaillera playback/lobby dialogs.

Testing

• Built and ran locally (macOS, GAME_STATS=ON) against real Smash Remix
  matches, including a match recorded on the schema-3 (RNG seed + Remix
  settings) build; confirmed the writer produces well-formed files
  (header, compression, event stream all parse back out correctly against
  the spec).
• Validated end-to-end against the companion reader/viewer tooling.
  rmgr-ts (the TypeScript
  reader/writer) has been updated through schema 3 and correctly parses
  files this writer produces, including the schema-1/2 backward-compat
  path (older files still parse with the new fields simply absent).
  rmgr-viewer (which
  consumes rmgr-ts) surfaces the RNG seed and Remix Gameplay/Stage
  Settings in its Replay Info panel.
• CI: build-linux/build-windows matrices exercise both GAME_STATS=ON
  and GAME_STATS=OFF across Debug/Release.

Known limitations

Called out in docs/RMGR_SPEC.md §9 in full; the notable ones:

• Core-layer recording is currently only reachable for the recognized
  game family. The wire format supports a game-agnostic, input-only
  recording for any N64 title, but the actual recording trigger
  (OnFrame()'s state machine) still depends on Smash-specific memory
  reads (ReplayMemory::IsInVsMatchScreen()/ReadMatchInfo()) with no
  generic replacement wired up yet - flagged explicitly in code comments
  as a follow-up (a game-agnostic PIF-level controller/frame source, of
  the kind already used for Kaillera netplay sync, would be the natural
  fit).
• Most of Smash Remix's settings surface beyond Gameplay/Stage Settings
  still isn't captured. MatchSettings now records the RNG seed plus
  all 31 Gameplay Settings and 8 (core) Stage Settings, but Remix also has
  Music Settings, Player Tags, and ~18 named plus ~170 auto-generated
  per-stage/per-track random-pool toggles that are deliberately out of
  scope for now.
• Item/weapon tracking has no velocity, damage, owner/attacker port, or
  expiration data yet - ItemUpdate records a named kind, position, and
  (as of schema 2) render scale, but nothing further has been mapped in
  memory.
• Stage hazard tracking covers exactly one hazard - Whispy Woods' wind
  on Dream Land.
• No aggregate damage-dealt/taken breakdown, or incoming-damage-this-hit
  field, even though the emulator exposes them.
• MatchEnd.endReason cannot currently distinguish time-out from
  stock-out - both collapse to a generic "normal end".
• No ROM-identity check for the extension layer. Nothing currently
  verifies the loaded ROM matches gameFamily's expectations beyond the
  goodName string comparison; a mismatch would produce an extension layer
  full of garbage bytes rather than falling back to core-only recording.
  This is a correctness gap to close, not an accepted design limitation.