XenonAnalyse: optional switch-aware block walker for forward-jumping switch tables

[Uproared]

Problem

Function::Analyze's block walker terminates on unconditional bctr
without pushing any successor blocks (function.cpp:149, 190-217).
The end-of-Analyze discontinuity sort-and-erase (function.cpp:237+)
then drops every block past the first address gap. For functions
whose primary control flow is switch-dispatched, this shrinks
fn.size to end roughly at the bctr, and every case label beyond
that point falls outside [fn.base, fn.base + fn.size).

Downstream consumers that do a containment check on switch labels
against this fn.size — notably XenonRecomp's recompiler
(XenonRecomp/recompiler.cpp:633) — then emit "Switch case trying to
jump outside function" warnings and replace the would-be
goto loc_<label>; in the generated C++ with // ERROR + return;.

The switch labels are, in fact, reachable (the bctr's computed
target at runtime is one of them). They are only "outside function"
from the block walker's perspective, because the walker didn't know
which targets the bctr could reach and conservatively pruned them.

Fix shape

Teach Function::Analyze about switch dispatches via a new optional
parameter:

static Function Analyze(const void* code, size_t size, size_t base,
                        const AnalyzerSwitchTableMap* switchMap = nullptr);

When the caller hands in a populated map keyed by BCTR guest VA, the
walker's unconditional-bctr path pushes every label (and the
default) as a successor block via the existing SearchBlock-guarded
emplace_back path. The end-of-Analyze discontinuity erase is
skipped when any route-A push fired (tracked via a local
switchAwareTermination flag), because switch dispatch leaves a
legitimate address gap between `bctr+4` (end of pre-switch block)
and the first case label — the jump-table bytes themselves live in
that gap, and the discontinuity heuristic would erase exactly the
blocks we just worked to make reachable.

Null-map safety is strict: when `switchMap == nullptr` (the
default), the switch-aware branch is skipped entirely and the walker
uses the legacy code path byte-for-byte. Every existing caller gets
identical behavior without any source change.

Commits

1. `XenonAnalyse: add optional AnalyzerSwitchTableMap parameter to Function::Analyze` — signature only, no behavior change.
2. `XenonAnalyse: block walker uses switchMap to push successors at known bctrs` — walker change.
3. `XenonAnalyse: add synthetic PPC fixtures for switch-aware walker` — three hand-crafted tests (happy path, null-map safety, wrong-map miss).

Tests

`XenonAnalyse/tests/switch_aware_walker_test.cpp` exercises:

• Happy path: switchMap populated, walker extends fn.size through the default label block.
• Null-map safety: switchMap == nullptr, legacy truncation preserved.
• Wrong-map miss: switchMap has an entry for an unrelated bctr VA, walker falls through to legacy.

All three assert on fn.size landing in the expected range. The tests are self-contained synthetic bytecode; no proprietary test corpus required.

```
[ok happy-path] fn.base=0x10000, fn.size=0x38, blocks=7
[ok null-map ] fn.base=0x10000, fn.size=0x1C (legacy walker truncation preserved)
[ok wrong-map] fn.base=0x10000, fn.size=0x1C (unrelated map entry correctly ignored)
All 3 tests PASSED
```

CMake integration for the tests is NOT included — happy to add an opt-in `-DXENONANALYSE_TESTS=ON` target or merge into an existing test harness if one is preferred.

Key design choice

The map is keyed by BCTR guest VA, not by XenonAnalyse's own `SwitchTable::base` (first-instruction-of-pattern VA). The caller does the switch-base → bctr-VA offset math at map-construction time (including handling any NOP padding between MTCTR and BCTR that some compilers emit for alignment), and hands the walker a pre-keyed map. This decouples the walker from pattern-length / pattern-type knowledge and keeps the walker simple.

Observed impact

A downstream recompile project (Xbox 360 PPC binary; decades-old compiler output) was emitting 2,304 "Switch case trying to jump outside function" warning lines across 76 unique bctr sites before this change. After wiring the optional switchMap into the recompiler's Function::Analyze call sites, 74 of 76 sites resolve cleanly (97.4%); the two residuals are unrelated pre-existing edge cases in switch-table ScanTable heuristics and are not route-A regressions.

Happy to adjust naming, split differently, fold tests into an existing runner, or any other shape you'd prefer.