add cargo-gpu new

[Firestar99]

• cargo-gpu new effectively aliases cargo generate with the rust-gpu-template repo
• This makes cargo-gpu depend on cargo-generate, which significantly increases the amount of dependencies cargo-gpu has. I expect most users to migrate to cargo-gpu-install for their build script needs.
  • if you really need cargo-gpu as a dep, I've made cargo-generate a default feature you can disable
• cargo generate also depends on quite a few outdated packages, including vulnerabilities, making our cargo deny complain. I've made it pass by ignoring them all, as I don't think there's a huge concern for a dev cmdline tool.

close #576

[LegNeato]

Wait, we have cargo-gpu, spirvbuilder, and cargo-gpu-install?!?! That seems really bad and confusing.

Can't we just put this behind an off-by-default flag (looks like it is on?) that is turned on for the binary? That way people using cargo-gpu in teh build script don't get changes in behavior and we still get this feature.

So I guess I don't see why cargo-gpu-install even exists?

[Firestar99]

Can't we just put this behind an off-by-default flag (looks like it is on?) that is turned on for the binary?

No we can't, cause if you cargo install, it'll always build the binary with the default feature set. So if we were to hide binary-only features behind a feature flag, noone would use them, cause noone will pass extra --features when installing a binary. Especially something like cargo new, which is primarily for newer users to give them a preconfigured rust-gpu workspace. We also didn't find a way to configure cargo install to pass additional features when building a crate.

So our only option was to split the crate in two, a library crate for build scripts (cargo-gpu-install) and a binary crate for cli usage (cargo-gpu). And since we wanted cargo install cargo-gpu to work, the cli crate has to be named cargo-gpu, so we named the library cargo-gpu-install since it'll only contain the Install action. It's only purpose is to install the rustup toolchain, build the codegen backend, and return you an InstalledBackend, from which you can create a SpirvBuilder (see cargo-gpu-install's readme). This split has also cuts out many cli-related dependencies like clap, crossterm and mio (async file io).

For additional background:

• The original PR: Split install action into the new crate cargo-gpu-install cargo-gpu#132
• much of the crate splitting discussion is in: Divide project into library and binary parts cargo-gpu#112

[LegNeato]

Ahhh, I see. Thanks for explaining.

[LegNeato]

Make this configurable with this as the default so you can point at branches or whatever to test?

[LegNeato]

We should support --lib and --bin like cargo, right now it assumes a certain opinionated shape. How do we specify shader types to include or not include? I glanced over the template and it seems to assume graphics. Should we default to compute (less boilerplate / host code needed) and be able to specify which shader stages to generate? Should we even have a default?