[plugin] Add swift-static-sdk cross-compile option (no container)

[sebsto]

Fixes #332.

Adds --cross-compile swift-static-sdk to lambda-build. It compiles a statically linked, musl-based binary directly on the host using the Static Linux SDK, with no Docker or container involved. The resulting bootstrap runs as-is on the Lambda provided.al2023 runtime.

What it does

• New StaticLinuxSDKBuildBackend that shells out to swift build --swift-sdk <triple>, slotting into the existing BuildBackend abstraction. No changes to the archive or deploy paths.
• --architecture selects the target: arm64 maps to aarch64-swift-linux-musl, x64 to x86_64-swift-linux-musl. Because the SDK genuinely cross-compiles, either architecture can be built from either host.
• The SDK must be installed beforehand. The plugin cannot download it (the sandbox limits network to Docker), so the backend detects a missing SDK and fails with install guidance instead of hanging or erroring cryptically.
• Detection uses swift build --swift-sdk <triple> --show-bin-path, which resolves the SDK exactly as the real build does. It does not parse swift sdk list, whose output is SDK bundle ids that never contain the target triple.
• The nested build runs in a dedicated --scratch-path under .build. The command plugin holds the workspace lock on the default .build for its whole run, so a nested build against the same directory would deadlock waiting for that lock. A separate scratch path avoids it.
• The plugin rejects flags that only make sense for a container build when this method is selected (--base-docker-image, --swift-version, --disable-docker-image-update, --base-oci-image, and --archive-format oci), rather than silently ignoring them.

A note on binary size

Building the same trivial Lambda both ways (release, stripped), the static-linux-sdk binary is about 16 MB and the container (glibc) binary is about 19 MB. The two are closer than you might expect, and the reason is worth recording: both statically link the Swift standard library via --static-swift-stdlib, so their .text sections are within a few KB of each other (around 11 MB each). The C library is the small part. musl links statically and stays compact; glibc is not statically linked at all in the container build, it stays dynamic. So the size floor for both is the Swift runtime, not libc, and static musl comes out slightly smaller rather than larger. If we want to reduce size further, the lever is the Swift stdlib footprint, not the choice of libc.

Testing

• Unit tests for backend selection, the musl triple mapping, and config parsing.
• Verified end to end against the 6.4 dev snapshot: builds a statically linked aarch64 ELF, packages it into a zip containing bootstrap, and writes a build manifest recording arm64.
• Verified the incompatible-flag errors fire, and that the plain and --archive-format zip paths still build with no false positives.

Semver: minor.