Fix UI test runner flag handling and recursive provenance resolution

[cds-amal]

This PR rewrites the UI test runner to actually respect //@ compile-flags: directives (previously silently ignored), and fixes a panic in provenance type resolution that crashed on nested struct fields.

• Rewrite run_ui_tests.sh: flag-based CLI, build-once-then-invoke (eliminates cargo freshness overhead per test), arch-aware skip logic, optional --save-debug-output for failure triage
• Add extract_test_flags() to both runners: parses //@ compile-flags:, //@ edition:, and //@ rustc-env: directives from test files
• Fix get_prov_ty to recursively walk nested struct/tuple fields instead of requiring an exact byte-offset match at the top level
• Replace panicking unwraps in get_prov_ty with graceful fallbacks

UI test results: 19 failing -> 2 failing, 2871 passing -> 2888 passing.

What was wrong

Two independent problems, both surfaced by investigating the 19 UI test failures on the master branch.

1. Test runner ignoring compile-flags directives

The UI test runners (run_ui_tests.sh, remake_ui_tests.sh) never extracted //@ compile-flags:, //@ edition:, or //@ rustc-env: directives from test files. Every test ran with bare -Zno-codegen regardless of what the test required. 17 of the 19 failures were compilation errors caused by missing flags (e.g., --edition 2021, --test, -Zunstable-options, -Ccodegen-units=1).

These tests were "failing" for the wrong reason: they weren't testing stable-mir-json at all, just failing to compile.

2. Provenance type resolution panicking on nested structs

get_prov_ty used field_for_offset (exact byte-offset match) to find which field a provenance pointer belongs to, then returned that field's type directly. This works when the pointer sits at the start of a top-level field, but breaks on nested structs.

Concrete example: TestDescAndFn has fields at offsets 0 (TestDesc) and 128 (TestFn). A pointer at byte offset 56 sits inside TestDesc (which itself has a &str field at relative offset 56). The old code looked for a field starting at exactly offset 56 in the top-level struct, found nothing, and panicked.

The fix adds field_containing_offset (range-based: finds the field with the largest start offset <= target) and makes the struct and tuple branches recurse into the containing field with a relative offset, walking down through the field hierarchy until reaching the actual pointer type.

Test runner changes

The rewritten run_ui_tests.sh:

• Flag-based CLI: --verbose, --save-generated-output, --save-debug-output replace positional args and env vars
• Build once: runs cargo build upfront, then invokes the binary directly with proper DYLD_LIBRARY_PATH/LD_LIBRARY_PATH setup (cuts ~2-3s of cargo freshness checking per test)
• Arch filtering: skips tests gated on foreign architectures via path matching and //@ only-<arch> directive parsing
• Flag extraction: extract_test_flags() parses //@ compile-flags:, //@ edition:, and //@ rustc-env: directives
• Debug output: --save-debug-output captures stderr on failure to tests/ui/debug/<test_name>.stderr and prints a 4-line snippet inline

remake_ui_tests.sh gets the same extract_test_flags() function so regeneration respects directives too.

Remaining failures

Test	Exit	Root cause
tests/ui/issues/issue-26641.rs	101	rustc internal panic ("escaping bound vars"); not a stable-mir-json bug
tests/ui/sanitizer/cfi/drop-in-place.rs	101	Missing -Ccodegen-units=1 in the test file's //@ compile-flags: directive; every sibling CFI test has it, this one doesn't. Upstream test bug, not ours.

Test plan

• cargo build clean
• Full UI test suite on Linux: 2888 passing, 2 failing (both known, neither ours)
• make integration-test

[dkcumming]

Nice! Awesome improvements to the scripts, and awesome solving of the bugs.

I started to make a new commit that was going to enforce that $RUST_REPO was checked out to the same commit we require for stable_mir_json so the tests are compatible. It happens for docker but not locally. When doing it I got some scope creep when I starting thinking we should have a utils.sh file for shared commands - so instead let's merge this and worry about things like that later!