Updating target json support

[Firestar99]

cargo gpu: Rust-GPU/cargo-gpu#75

This is the first PR to update the target spec jsons, which causes cargo gpu to run into some trouble. The codegen backend verifies that these jsons match exactly what it expects, and there's no flag to skip that check, and adding one now wouldn't help since we want to keep compatible with at least 0.9.0. Cargo gpu was never designed to have multiple target-spec versions, it always just used the latest. [...]

#249 (comment)

Could we move the target jsons from spirv_builder to rustc_codegen_spirv-types? That would allow cargo-gpu to resolve the required target jsons from rustc_codegen_spirv depending on rustc_codegen_spirv-types (and spirv_builder will retain access to it). If we can't find any target jsons in rustc_codegen_spirv-types, we can just fall back on the current target jsons, which we'd have to ship with cargo-gpu for the forseeable future. But I think that's a fine compromise, at least we wouldn't need to ship all future target jsons as well.

#249 (comment)

[LegNeato]

Should this be its own crate? @eddyb and I discussed it in the past.

[Firestar99]

You mean just the target specs json files as a separate crate? And have cargo gpu to just permanently depend on the "legacy" version of the target specs? (legacy meaning before this PR)

Just one issue with that: spirv-builder wants the path to the json files so it can point rustc to them, which is ensured to exist by directly depending on that crate. But in cargo gpu the legacy target jsons are include_str! into the binary, so we don't depend on those legacy json files remaining within cargo's crate cache. Which may be reset independently of the cargo gpu installation.

[LegNeato]

Yeah the json as their own crate. Doing so lets us have multiple versions and doesn't bring in other deps if something just needs the json. As I said we discussed it in the past but I think just kicked the can down the road until problems cropped up. We may now be there ha