utils: SxS-bind toolchain runtime for Stage2 compiler tests

Stage2 compiler tests load swift toolchain executables (`swift-frontend`,
`sourcekitd-test`, `swift-ide-test`, `swiftc-legacy-driver`,
`swift-backtrace`) that were built linked against a specific swift
runtime — the Toolchain SDK current at Stage2 link time.  At test time
the same `bin\` is repopulated by `swift-test-stdlib` with a
*different* runtime (the freshly Stage2-compiled stdlib), and standard
Windows DLL search resolves to the EXE directory first.  Without
intervention the toolchain ends up loading whichever stdlib happens to
be there, with predictable ABI mismatches (e.g. an illegal-instruction
trap in `swift_checkMetadataState` on `DecodingError.Context` during
plugin JSON message decoding).

`Set-WindowsSxSToolchainRuntime` mints a private SxS bundle next to
each tool that pins its runtime to the toolchain SDK's `usr\bin\`
regardless of DLL search order.  `Test-Compilers` invokes the bind
after Stage2 builds so the test infrastructure runs against a stable,
known-compatible runtime.

The bind list grew by evidence — every entry traces back to a test
that crashed in `swift_checkMetadataState` with the wrong
`swiftCore.dll` in stack-frame 0.  See the in-source comment for the
per-tool justification.

Test-Compilers also now sets `SWIFT_BUILD_LIBEXEC=YES` and
`SWIFT_HOST_SDKROOT=<toolchain SDK>` so check-swift's
`swift-backtrace-${SDK}` dep chain is wired and `%host-build-swift`
in lit.cfg sees the right host SDK.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: compnerd