proposal: "spin buildx" plugin

I wrote a plugin spin terminal (https://github.com/rajatjindal/spin-plugin-terminal) based on dagger, which provides a container shell with the required toolchains.

As i played around with that concept more, I thought what would be really cool is to have something like spin buildx, which reads the toolchain requirement for a specific spin app (in a .toolchains file), spins up a container with the required toolchain, run spin build and export the build artifacts back to host system.

I did a small poc of that and it seems to have worked for simple cases I tried:

$ spin new -t http-rust http-rust-buildx --accept-defaults

$ cd http-rust-buildx 

$ cat >> .toolchains<< EOF                                       
rust=1.82.0
spin=3.1.0
EOF

$ ls ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm
ls: ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm: No such file or directory

$ ../spin-terminal/buildx
✔ connect 0.2s
✔ loading module 0.7s
✔ parsing command line arguments 11.2s
✔ wasi: Wasi! 0.7s
✔ Wasi.build(
    source: ✔ ModuleSource.resolveDirectoryFromCaller(path: "."): Directory! 0.0s
  ): Directory! 1m24.0s
✔ Directory.export(path: "."): String! 2.4s

Full trace at https://dagger.cloud/rajatjindal/traces/4378964d0128b39a071bdd0bb8fe4993

/Users/rajatjindal/go/src/github.com/rajatjindal/http-rust-buildx
closed the terminal succcessfully

$ ls ./target/wasm32-wasi/release/deps/http_rust_buildx.wasm
./target/wasm32-wasi/release/deps/http_rust_buildx.wasm

if we include this toolchains file in examples/templates (or as a spin.toml entry as suggested by @itowlson), then using this plugin will significantly reduce friction for new users. e.g. while for rust, the toolchain requirement is simple, but for golang, we need golang, tinygo and wasm-tools and then installing specific versions of that, all that can be simplified.

Please let me know your thoughts.

Start by reviewing the referenced spin-plugin-terminal proof of concept and the proposed .toolchains file, then inspect examples/templates and the possible spin.toml entry mentioned in the issue. Done would mean a spin buildx workflow can read an app's toolchain requirements, run spin build in a container, and export the build artifacts to the host.