Templates: support Cargo workspaces

[itowlson]

The current Rust templates generate a set of separate workspaces:

- app
  |- comp1
  |  |- Cargo.toml
  |- comp2
     |- Cargo.toml

with separate build commands for each.

This means each component gets a separate IDE experience, separate compilation, etc.

If we also had a workspace at the top level, with the components as workspace members:

- app
  |- Cargo.toml  // New! Exciting!
  |- comp1
  |  |- Cargo.toml
  |- comp2
     |- Cargo.toml

then app developers could open the top-level directory and work on all components in their application in a single IDE, and would benefit from shared compilation of dependencies (once a dependency had been compiled for one package in the workspace, it would not need to be recompiled for others). This is a non-trivial speedup for all the Wasm shenanigans drawn in by the Spin SDK!

This would involve some changes to the Rust template:

• Build command is cargo build --release --target wasm32-wasi -p <name>
• Directory for the .wasm file is target/wasm32-wasi/release rather than <name>/target/wasm32-wasi/release
• No workdir
• So watch paths need to include the directory (unless we keep workdir but somehow kerjigger its semantics)
• Aaaaand... we need to add each project to the top-level Cargo.toml's workspace.members

There is also some structural stuff:

• We now also need to create a single top-level Cargo.toml - we can do this as the new part of the new-add cycle
• As far as I can tell, we need a dummy top-level src/lib.rs because otherwise rust-analyser gets mad because it wants to run cargo check, and that fails if the top-level Cargo.toml doesn't have any code associated with it. I don't know if there's an option to suppress this.

The main challenge with this is editing the existing Cargo.toml to update the workspace.members array. The existing template system should be able to handle the rest, but it can't do that. It's probably not difficult but it's a very Rust-specific feature and I would really like to start getting that kind of stuff out of the template system and into "smarter" templates. Oh well.

Anyway this feels like it makes for more pleasant edit and build experiences for multi-component Rust projects.