Rework the Mono and IL2CPP support around per-build offset profiles

[ero-qt]

The Unity support currently guesses layouts: versions from FileVersion thresholds and memory string scans, offsets from four hand-kept eras per backend. A wrong guess is indistinguishable from "not loaded yet" and shows up as an infinite wait.

Some concrete problems:

• Unity 2023.x IL2CPP matches no arm of the version detection and falls back to Version::Base, the oldest layout.
• Mono version detection on ELF/Mach-O silently defaults to V2 when its string scan misses.
• IL2CPP attaches on Windows x64 only; nothing below UnityPointer caches; no nested classes or generic instances.

The plan:

• Identify instead of guessing: Mono by the runtime binary's identity (PE debug GUID, ELF build-id, Mach-O UUID), IL2CPP by (metadata version, Unity version, pointer size).
• Offsets become data: per-build profiles generated offline from Unity's own symbols, compiled into static tables. Supporting a new build is a data drop, not new code.
• One shared metadata walk over both runtimes, with a small set of per-runtime operations for where they genuinely diverge.
• Unknown binaries fail loud with what was read instead of attaching with a neighbour's offsets.

Module::attach(process, version) can stay as a thin layer while the new surface lands. Follow-ups are tracked separately: managed string and collection reads in #149, the scene manager and time manager rework and engine-shared extraction later.

PRs

In order, each building on the ones before it; every body says what it depends on.

• Add build identity reads for PE, ELF and Mach-O #142
• Add measured offsets for known mono builds #143
• Add measured offsets for known IL2CPP builds #144
• Share one metadata walk between Mono and IL2CPP #145
• Resolve nested classes, generic field counts, and inherited statics #146