Switch spirv_headers to SemVer

[Jasper-Bekkers]

See #117 and #196

Because spirv_headers doesn't follow SemVer, making changes to it, and keeping downstream dependencies from breaking we should switch over to SemVer and ditch the Vulkan / SPIR-V numbering scheme and instead just document which SPIR-V version corresponds to the current crate version. This should solve most of the problems in the future (but may introduce some confusion around which SPIR-V version is exposed instead).

I think it's probably better to have that confusion during development, rather then breaking downstream builds.

[Jasper-Bekkers]

If we wanted to continue to encode the spirv spec - we might be able to encode it into the patch version instead. However, I'd much rather just stick to regular SemVer without any fancy additions like this.

@antiagainst also suggested just publishing this crate under a new name (spirv instead of spirv_headers) and starting over with semver. Though personally I'd also be fine with just bumping this crate to 0.2 since that doesn't correspond to a SPIR-V version either.

[antiagainst]

I've pinged @neon64 on #21 regarding the spirv crate. Hopefully we can switch to that crate with a clean slate. Or we can also start with v2 of spirv_headers and using that going from now. My preference is the first; but either way works for me.

[Jasper-Bekkers]

To restore some order to the world I'll yank both rspriv 0.8.0 and spirv_headers 1.5.1 while we wait for a reply. (And alternatively just publish v2 of spirv_headers right after, if we care) so we can work this out in the meantime.

@kvark any objections to yanking these versions?

[kvark]

much appreciated, thank you!

[MarijnS95]

We could possibly use Version Metadata to include the spirv version, that ends up looking like 0.8.0+1.5.2 (useful in crate and perhaps tag history). This metadata is only informational and otherwise ignored, cargo even recommends against specifying it in [dependencies].