Divide project into library and binary parts, round 2

[tuguzT]

This is just a fresh redo of #112.
After re-reading discussions of the previous PR, I've came to conclusion that I should reimplement it to split library/binary parts more aggressively (to remove unnecessary dependencies inside of build scripts).

Fixes #105

Requires:

• Return JoinHandle of watching thread to the caller rust-gpu#413
• Debug for CargoCmd rust-gpu#415
• Make AcceptFirstCompile public rust-gpu#417
• Redesign spirv-builder's watch API rust-gpu#422

This PR uses move-then-modify trick in order to preserve file history of changes.

---

Here is the recap:

• added new crate rustc_codegen_spirv-cache which responsibility is to install backend codegen dylib (compile it & move inside of cache directory)
• added new crate cargo-gpu-build (library part of the project) which handles building of shader crates
  this crate could be used inside of build scripts, something like this:

let builder = SpirvBuilder::new(SHADER_CRATE_PATH, "spirv-unknown-vulkan1.2")
    .shader_crate_default_features(false)
    .shader_crate_features(["nightly".into()])
    .spirv_metadata(SpirvMetadata::Full);
let compile_result = CargoGpuBuilder::new(builder)?.build()?;

• cargo-gpu is a CLI (just the same as before), some of its internals was just moved into the crates above

---

Open questions:

• should ShaderCrateBuilder be renamed into CargoGpuBuilder?

[tuguzT]

I've noticed just now that Config & Metadata structs of cargo-gpu are tightly linked & depend on Build implementing clap::Parser.
If we would like to support [metadata.*] section of Cargo.toml inside of build scripts, these structs should be decoupled from cargo-gpu's Build struct & moved inside of cargo-gpu-build.

In the near future, I'll try to make it possible, but not sure when exactly...

P. S.: First of all, I could remove shader_crate field from Install struct of newly created codegen backend cache crate and move it inside of cargo-gpu crate...
Or I could point out what fields should be touched by Config and Metadata...

[Firestar99]

If we would like to support [metadata.*] section of Cargo.toml inside of build scripts

Yes please, though could also be in a future PR.

Background: If we ever want to support cargo gpu clippy (see Rust-GPU/rust-gpu#347), we'd want the cargo-gpu cmdline to have the same configuration as is used in the build script. But since we can't parse the config from the build script, we'd need the "default" configuration in the [metadata.*] section of the Cargo.toml. We could then offer an SpirvBuilder::from_cargo_metadata() to load those values and allow the build script to adjust them before running, to allow compiling multiple different variants (like different capabilities or features).
Not yet sure if we want it to be parsed at SpirvBuilder or at cargo_gpu::Install level. As spirv-builder already needs serde_json, we already got the serde dependency and adding toml parsing won't be a big deal. Though I think we should keep clap behind a feature gate.