[plugin] Refactor lambda-build into pluggable build backends + thin-layer plugin args

[sebsto]

Summary

Refactors the internals of the lambda-build build path into a pluggable backend
architecture, and tidies the plugin→helper argument plumbing. This is an internal
refactor: no user-facing flag, no --cross-compile value, no output ZIP path, and
no public Swift API changes. Behaviour is identical; the goal is to make adding new
cross-compilation backends (podman, finch, colima, swift-static-sdk, custom-sdk, …)
a localised, additive change.

1. Pluggable build backends (lambda-build)

The build logic in Builder.swift was a hard-coded native-vs-docker/container
branch with an enum (CrossCompileMethod) that carried both the parsed user choice
and the argv-building logic. It's now split along two independent axes:

• BuildBackend protocol — how a build runs: NativeBuildBackend (on an
  Amazon Linux host) and ContainerBuildBackend (inside a container).
• ContainerCLI protocol — the argument flavor of a container runtime:
  DockerCLI and AppleContainerCLI. A single ContainerBuildBackend serves both
  (and future runtimes) since only the argv spelling differs, not the build flow.

CrossCompileMethod keeps only the parsed value, parse(...), and a
makeBackend(configuration:) factory; its pullArguments/runArguments (and the
fatalError SDK stubs) are gone. Builder.build(...) is now select-and-delegate
(~8 lines); Builder.swift shrinks from ~700 to ~460 lines.

No shared argv helper between CLIs — by design. Each ContainerCLI builds its
complete argument vector independently (no base struct, no default implementation,
no shared closure). docker and Apple container argv may diverge in future CLI
versions, and future runtimes may not be compatible at all; a shared helper is
exactly the coupling that caused the earlier docker/container mix-up (#678). Each
CLI is covered by its own golden-argv tests with no shared fixtures.

Adding a backend later is now additive: a new *CLI.swift + a CrossCompileMethod
case + one line in makeBackend (container runtimes), or a new BuildBackend type
(SDK methods). No edits to Builder or existing CLIs.

File layout:

lambda-build/
  Builder.swift                 # build() select+delegate, package(), BuilderConfiguration, BuilderErrors
  CrossCompileMethod.swift      # enum + parse + makeBackend factory
  Backends/
    BuildBackend.swift          # protocol
    NativeBuildBackend.swift
    ContainerBuildBackend.swift
    ContainerCLI.swift          # protocol
    DockerCLI.swift
    AppleContainerCLI.swift

2. Thin-layer plugin argument plumbing

The plugins are meant to be the thinnest possible layer: resolve only the values
that need PluginContext / the package graph, then forward everything else to the
helper. lambda-build and the deprecated archive (Swift 6.4 passthrough) were
re-appending the original arguments after extracting some, so options like
--products reached the helper twice (and, for --products, caused the product to
be built twice). Both now forward argumentExtractor.remainingArguments, so a
consumed option is never forwarded again.

The same one-line bug (+ arguments → + argumentExtractor.remainingArguments) is
fixed in lambda-deploy, which had it too.

The internal plugin→helper flag --docker-tool-path is renamed to
--cross-compile-tool-path (and the config field dockerToolPath →
crossCompileToolPath) so it no longer implies docker — it can carry any
cross-compile tool. This flag is internal (plugin→helper), not user-facing.

Note: the deprecated pre-6.4 archive implementation (Plugin.swift, behind
#if swift(<6.4)) is intentionally left untouched.

Testing

• New BuildBackendTests.swift: separate golden-argv tests for DockerCLI and
  AppleContainerCLI (no shared fixtures), plus makeBackend factory tests
  (docker → DockerCLI, container → AppleContainerCLI, SDK methods throw).
• All AWSLambdaPluginHelperTests pass (84 tests); swift build and
  swift format lint --strict clean.
• End-to-end against a sample project: lambda-build default (docker) and
  --cross-compile container emit byte-for-byte identical argv to before the
  refactor; --products is no longer doubled.