Fix macOS host arguments and universal Unity startup

[johanntan]

A universal macOS Unity game can start without working hooks, ignore --melonloader.basedir, or resolve its game data path outside the actual app bundle. This fixes three independent startup problems encountered with A Dance of Fire and Ice 3.3.1 (Unity 6000.3.10f1), using the supported x64 loader under Rosetta.

• Read host argv through _NSGetArgc/_NSGetArgv on macOS. Environment.GetCommandLineArgs() in the NativeAOT bootstrap does not expose the native game's arguments. Existing option parsing and syntax are unchanged.
• Obtain the native executable path using _NSGetExecutablePath, decode UTF-8, and find the enclosing Unity app bundle. Process.MainModule can identify a different module in an embedded runtime. Keep the public macOS GameExecutablePath convention of returning the app bundle.
• Replace the bundled x64 libplthook.a with a rebuild that accounts for universal Mach-O slice offsets when reading chained fixups. The exact source revision, build command, deployment target, and license are recorded beside the archive. The archive contains a single rebuilt object.

Dependency status: kubo/plthook is archived; GitHub rejected an upstream PR as read-only. The tested source fix is available for review at johanntan/plthook#1. This MelonLoader PR is a draft for review of that dependency and coordination with #1174. The native path fix overlaps that PR's app discovery changes, but this PR does not add arm64 loader targets, interposition changes, or another launch wrapper.

Validation

• Added bash tests/MacHost/run.sh: a C executable loads a NativeAOT shared library linking the production parser and environment class. It checks separate/equals basedir syntax, empty values, embedded equals, UTF-8 values and app paths, flags, and a loader directory outside the app. Both x64 and native arm64 helper runs pass; the latter does not claim full arm64 loader support.
• With the original argument source substituted, the same harness fails the host basedir check. With only the original environment source substituted, it fails app discovery.
• Normal solution Debug and Release builds pass on macOS with warnings, without the earlier local PDB-conversion bypass. Managed net35, net472, and net6 targets also compile with Windows and Linux platform guards; their runtimes were not exercised here.
• plthook's existing suite and new thin/universal/fat64 regressions pass on x64 and arm64. Each fixture exercises all three open APIs. The rebuilt archive was verified to contain the corrected implementation.
• Timed headless game startup reaches the main menu with no mods, and with ADOFAI Access in a separate base directory containing spaces and Unicode. The mod loads and initializes its AVSpeech backend. No game assets are included.

Launch and validation limits

The existing melonloader-launch.sh works when invoked through an x64 shell on this Apple Silicon Mac. The equivalent Steam launch-option form is:

/usr/bin/arch -x86_64 /bin/bash "/absolute/game/path/melonloader-launch.sh" %command%

The wrapper invocation was tested directly with the game's app-bundle argument; launching through Steam's UI was not tested. Without explicit architecture selection, dyld rejects the x64 bootstrap in the arm64 game. No changes to that wrapper are included.

These are startup checks, not a full gameplay or clean-exit certification. The game remained running until the test timeout; SIGTERM cleanup ended in SIGABRT in the with-mod and no-mod loader runs. Interactive gameplay and normal in-game shutdown still need validation.