Move compilation for container images outside of Docker

We may be able to improve build cache granularity if we move rustc compilation out of Docker, and instead cross-compile on the host, then copy the resulting binary into an image layer. This is what Prometheus does with Go builds, via promu, and similar to how rules_oci for Bazel works. We would have to install support for an additional target via rustup, and invoke cargo build with --target x86_64-unknown-linux-musl (or just --target x86_64-unknown-linux-gnu if we switch to distroless, see divviup/janus-ops#742). Currently, with the cargo-bake approach, any change to Cargo.toml requires a full rebuild. With this approach, we would be able to reuse most .rlibs in that situation. There's also potential to reduce duplication of target directories between the Dockerfile images and the Dockerfile.interop/Dockerfile.interop_aggregator images. Note that this would also make building images for other architectures easier (#948), since neither ARM build hosts nor emulation would be required.

Start by reviewing the current cargo-bake flow and the Dockerfile, Dockerfile.interop, and Dockerfile.interop_aggregator images. Check how rustup targets and cargo build currently run, then assess host cross-compilation and copying the resulting binary into image layers. Done means the images build with reusable Rust artifacts while retaining the interop image behavior and enabling other architectures without emulation.