GSRunner: Batch mode and regression test mode

[TJnotJT]

Description

This PR introduces batch GS running and in-memory comparison to speed up GS regression testing. This is still a WIP — some features are incomplete or not fully tested. The PR is on the larger side — feedback and discussion on design choices are welcome.

Adds the following:

1. Batch mode for GS runner: Runs multiple dumps sequentially within a single PCSX2 instance. Buffers upcoming dumps to reduce I/O overhead.
2. In-memory regression testing: Runs three GS runner instances. Two instances run dumps and upload frames to shared memory, while a third compares frames and saves only those that differ.

Current status:

1. Batch runner: nearly complete and ready for testing.
2. In-memory regression testing: parts require rewriting and porting for non-Windows platforms.
3. Other small todos: cleaning up code, adding help for new args, etc.

Currently, this build only compiles with MSVC.

Rationale

1. The batch runner improves dump run times by avoiding repeated PCSX2 creation and buffering dumps in advance.
2. In-memory regression testing reduces I/O overhead further. This is helpful when testing multiple renderers or settings. For single-renderer runs, using precomputed baselines may still be faster.

Other notes

• Converting .xz dumps to .zst can improve decompression speed by 2–3x, though file size increases by a similar amount.

Testing steps (batch mode)

• Running dump tests and comparing results to master would be helpful (with non-DX12 renderers; see issues below).
• Frame outputs and statistics should match master except for the known issues below.
• You should also see a noticeable reduction in total dump run time.

Example usage (Python script):

python pcsx2-gsrunner/test_run_dumps_2.py \
    -runner <path to gsrunner> \
    -gsdir <path to dumps> \
    -dumpdir <path to output> \
    -renderer vulkan \
    -upscale 1 \
    -parallel 2 \
    -gsfastreopen &

Use this to compare with the results from running test_run_dumps.py in master.

Example usage (executable):

pcsx2-gsrunnerx64.exe <path to dumps> -batch -nbatches 2 -batch-id 0 \
    -surfaceless -loop 2 -logfile <output path> -dumpdir <output path> \
    -renderer vulkan -noshadercache -batch-gs-fast-reopen &

pcsx2-gsrunnerx64.exe <path to dumps> -batch -nbatches 2 -batch-id 1 \
    -surfaceless -loop 2 -logfile <output path> -dumpdir <output path> \
    -renderer vulkan -noshadercache -batch-gs-fast-reopen &

• Run each instance separately with a unique -batch-id to execute them in parallel.
• In batch mode, -logfile should point to the directory where logs are saved (use the same directory as -dumpdir for behavior consistent with master).

Known issues

• Vulkan/OpenGL: In some dumps, newly created textures may contain leftover data from previous dumps and affect final frames. One case was due to an unrelated bug with valid-area computation. DX11 seems to be unaffected.
• DX12: Hangs after a few hundred dumps due to a resource leak (under investigation).
• Stats: The Texture Uploads stat can vary by 1–2 due to nondeterminism (affects both PR and master).

AI assistance

Reviewing code, approaches for threading, referencing system- or API-specific details, and drafting this description.