Support cross-compiling to Android with a Swift SDK

[AttilaTheFun]

Android support, part of the #1809 split, on top of the now-merged foundation
PRs #1820 (swift_binary(linkshared)) and #1821 (Swift-SDK framework). A sibling
of the WebAssembly PR (#1817); it does not depend on it.

What this adds

swift.android_sdk downloads the swift.org Android Swift SDK bundle and, using
the shared framework (#1821), defines a Swift toolchain targeting
{aarch64,x86_64}-unknown-linux-android. swift_binary(linkshared = True)
produces a JNI lib<name>.so whose entry points are written entirely in Swift.
examples/cross_compilation/android_app builds one and ships a complete,
runnable Android app that loads it and shows the Swift-computed greeting on
screen — with nothing preinstalled (no Android Studio, no device), one command
boots a hermetic emulator, installs, and launches it:

bazel run //examples/cross_compilation/android_app:run

The NDK comes from a cc toolchain, not from rules_swift

Per review feedback, rules_swift does not fetch or manage the NDK. C/C++
compilation and linking for Android targets go through a separately registered
Android C++ cc toolchain, and the Swift toolchain reads that toolchain's sysroot
at analysis time. So you bring an Android cc toolchain — e.g. @androidndk//:all
from hermetic_android_toolchains
— and register it alongside the Swift toolchain:

register_toolchains(
    "@swift_toolchain//:swift_toolchain_android_aarch64_xcode",
    "@androidndk//:all",
)

This keeps rules_swift out of the NDK-management business entirely (no NDK
download, no per-host repos, no bespoke C++ toolchain) and works with any
rules_android_ndk-based Android cc toolchain.

A few NDK-integration details that aren't obvious:

• CcToolchainInfo.sysroot from rules_android_ndk's toolchain reports the clang
  directory, not the sysroot, so the Swift toolchain derives the sysroot from the
  toolchain's files.
• The Swift binary link runs through cc_common.link with that cc toolchain, but
  rules_android_ndk reports its sysroot as the clang dir and exposes an empty
  dynamic_runtime_lib, so the toolchain adds --sysroot and stages
  libc++_shared.so itself. It also links libc++ as the shared runtime
  (rules_android_ndk links it statically by default — rules_android_ndk#93).
• To package libc++_shared.so into an APK, select_android_runtime_lib (in
  swift/toolchains/android_runtime_lib.bzl) selects it from the resolved cc
  toolchain.

The runnable example (examples/cross_compilation/android_app)

A real android_binary (built with rules_android + rules_kotlin, the
real-world way Android apps are packaged) completes the chain end-to-end:
MainActivity.kt → NativeBridge.greetingFromSwift() (Kotlin, JNI) →
libSwiftJNI.so (swift_binary(linkshared), @_cdecl) → Greeter
(swift_library).

The one rules_swift-specific detail: swift_binary(linkshared = True) exposes
its .so via DefaultInfo, not CcInfo, so it can't go straight into
android_binary.deps. Wrapping it in a cc_library (a prebuilt .so in srcs
becomes a CcInfo dynamic library) lets android_binary's per-ABI native split
collect it into lib/arm64-v8a/; libc++_shared.so goes in the same way via
select_android_runtime_lib.

rules_android / rules_kotlin / rules_java / rules_jvm_external (and the
hermetic emulator the :run target downloads) are all dev_dependency = True,
split into android_app/android.MODULE.bazel and include()d, with a pinned
Maven lock and the hermetic @androidsdk — so consumers of rules_swift are
unaffected and protobuf stays at 34.

CI

The example builds and tests in the normal macOS //examples/... job (the
@androidndk/@androidsdk toolchains come from hermetic_android_toolchains, dev
dependencies; the arm64 --android_platforms + a hermetic JDK are set in
.bazelrc). No emulator runs in CI; instead the Android path is guarded by:

• Analysis tests (//test:android) asserting the action command lines — the
  Swift compile targets aarch64-linux-android, and the link runs the NDK clang
  for the Android target against the NDK sysroot, linking the shared libc++ and
  staging libc++_shared.so.
• Artifact tests (build_test) running the NDK llvm-readelf on the built
  .so (AArch64 ELF, libc++_shared.so in NEEDED, the @_cdecl symbol
  exported in .dynsym) and asserting the APK packages both .sos under
  lib/arm64-v8a/ plus the dexed Kotlin.