No longer require crate-type = ["dylib"] on shader crates

[Firestar99]

With this PR, you no longer need to declare the crate-type in your shader crate.

All shader crates can now remove the previously required declaration in Cargo.toml below:

[lib]
crate-type = ["dylib"]

Changes

• no longer requires crate-type to be set in your shader crate
• switch spirv-builder from cargo build to cargo rustc
  • allows passing --crate-type=dylib
  • the difference between the commands is minor, rustc mostly just exposes additional rustc args for the target crate
• the cargo <cmd> is configurable
  • future investigation: may allow calling other cargo commands, such as clippy or fmt

close #476

cargo-gpu

Rust-GPU/cargo-gpu#125

Needs to be updated after this PR is merged, and needs some fixups from other changes in master, so a simple cargo patch won't work.

[LegNeato]

Could you include a comment for why we need dylib at all?

[Firestar99]

Did another cleanup round, found some more crates that declare crate-type=["dylib"] that I missed, and added a quick comment on crate types:

rust-gpu/crates/spirv-builder/src/lib.rs

Lines 1026 to 1030 in d7681df

	// About `crate-type`: We use it to determine whether the crate needs to be linked into shaders. For `rlib`,
	// we're emitting regular rust libraries as is expected. For `dylib` or `cdylib`, we're linking all `rlib`s
	// together, legalize them in many passes and emit a final `*.spv` file. Quirk: If you depend on a crate
	// that has crate-type `dylib`, we also link it, and it will fail if it has no shaders, which may not be
	// desired. (Gathered from reading source code and experimenting, @firestar99)

[Firestar99]

From cargo apk repository about using cargo rustc instead of cargo build:

The unfortunate downside of this, as shown by the last CI run is that we can no longer build multiple targets such as examples at once. Neither --examples nor explicitly specifying --example hello_world --example jni_audio --example looper is allowed, all result in error: crate types to rustc can only be passed to one target, consider filtering.

I don't think this affects us at all, since we're only ever building the --lib for shaders, never any examples or executables.

[LegNeato]

I'll let @eddyb review as I am not sure of ramifications.

[nazar-pc]

They already approved, but looks like the APIs used in the action to install Vulkan SDK on Windows is not using tokens, so it exceeds rate limits sometimes, which prevented merging: https://github.com/Rust-GPU/rust-gpu/actions/runs/19971068746/job/57275658889