I had to add a decent amount of debugging infrastructure to figure out wtf was going wrong when the default capabilities weren't enabled, and I figured I should clean up that infra and leave it in, so there's a decent amount of error message changes in this PR.

Also included is adding glam to system crates, because otherwise it barfs on all usages of e.g. f64 in glam if Float64 isn't enabled, and I don't want to force glam to write #[cfg(any(not(target_arch = "spirv"), target_feature = "Float64"))] everywhere (and Int8, etc.) - it'd be a maintenance nightmare, easily broken.

Also, compiletest gets all of Int8, Int16, Int64, Float64 automatically enabled for both the "library" crates (everything except for the compiletest'ed crate), as well as the final crate. I ranted about this in discord for as to why, I'm just going to copy that in instead of rewriting it:

uugggh, so, I'm nuking the "default Int8 capability", and running into really really annoying things in compiletest. The "standard library" crates in compiletest (everything except the end crate) is only compiled once, for every test. Say, it's compiled without the Int8 capability, and a test does enable the Int8 capability. This means that in the "standard library" crates, Int8 is zombie'd, however, in the test crate, it is not zombied. This means that if, say, the test crate calls a stdlib function taking a u8, the export in the stdlib has a zombie symbol, but the import does not have a zombie symbol, and so there's a linker type mismatch because two identical types where one is zombie and the other are not are considered distinct types. But, even if we merged, say, only Int8 types where one is zombie and the other isn't, the zombie status of the stdlib would "leak" into the end crate, and u8 would get zombie'd even if the test enables the Int8 capability.

So uh, running this by [eddyb] for sanity: I've thought about it a bit and I think the best solution is to enable all of Int8,Int16,Int64,Float64 for the compiletest "stdlib" and every test, to make sure there's no mismatches. It does mean that testing that particular part of the capability system would be impossible (since it's always enabled, we can't test an expected-failure), but, it should be fine, idk. This situation won't ever happen in the real world, since all crates in the graph are always compiled with the same capabilities.