[codex] Use only hermetic Swift toolchains

[dzbarsky]

Summary

• remove swift_autoconfiguration, @rules_swift_local_config, host swiftc lookup, and the Xcode toolchain lookup fallback
• generate Linux and Apple Swift toolchains from the downloaded swift.org archive, while continuing to use Xcode for Apple SDK and linker metadata
• add explicit platform selection to swift.toolchain and update repository setup, release notes, and CI configuration

Motivation

Host Swift discovery made compiler selection depend on PATH, installed Xcode toolchains, and repository evaluation environment. The registered Swift compiler should instead be an explicit, versioned Bazel input.

User impact

Root modules must declare the swift extension, select their build-host platforms, and register @swift_toolchain//:all. Apple builds still require Xcode for SDKs and linking, but Swift compiler actions use the downloaded hermetic toolchain.

Validation

• buildifier and clang-format
• generated documentation diff tests
• focused Swift toolchain, precompiled-module, and synthesized-interface tests
• bazel build //examples/apple/objc_interop:objc_interop //test/fixtures/synthesize_interface:synthesized_interface
• action inspection confirmed external/+swift+swift_toolchain_xcode/usr/bin/swiftc

The broader //test:precompiled_modules suite is blocked locally because the Xcode 15.4-generated @system_sdk repository does not contain Testing; the directly affected precompiled-module test passes.

[keith]

I think we should move to hermetic toolchains for windows / linux (and maybe provide toolchain entrypoints for the non-hermetic ones?) but for macOS you're not "allowed" to ship app store apps with the swift.org toolchains, so we have to keep using xcode for that.

i do also like the idea of dropping the custom toolchain support and instead use macOS hermetic ones for local testing of new toolchains, but that wouldn't support custom build toolchains either so we'd have to still make it work with that