Make sure we're not using any unsupported intrinsics in the various x86 levels

[valadaptive]

x86's SIMD support is a huge mess, and it's not clearly delineated by vector width. I noticed this when looking at #97: _mm_mullo_epi64 is not an SSE intrinsic nor even an AVX2 intrinsic, but requires AVX512! This is very hard to catch, and I only noticed it because Clippy flagged its usage as an MSRV violation.

We should add some sort of check to ensure we don't accidentally use any unsupported intrinsics on x86. My first thought was the Clippy disallowed_methods lint, but Clippy lints can only be configured on a per-workspace basis, and we need something that can vary per-file.

My idea is this: using whatever method @raphlinus used to generate the core_arch modules (it doesn't seem to be checked into the repository), we can gather a list of intrinsics that are supported at a given feature level. Then, for the generated implementations (currently sse4_2.rs and avx2.rs), we create an inner module that re-exports only the supported intrinsics from core::arch::x86_64, and wildcard-import from that inner module. This is done to avoid any "unused import" lint warnings while not requiring us to maintain a full list of every single intrinsic we call into.

[DJMcNab]

This issue is part of the impetus for #108, that is, instead of the current unsafe { blocks, we would have a call to trampoline with the correct argument types. This would unfortunately require a few contortions, and I think we'd also want to only have this in cfg(test) (or even a completely custom cfg), because of the potential compile time cost and accidental inlining suppression. That is to say, target_feature 1.1 already provides a way to check the safety of this, if we can find a way to let it.

I do really like the idea of splitting intrinsics into modules by level/target feature; in combination with #108 that would be really good for end-user ergonomics; I would however not want to maintain this with a safety guarantee. Unfortunately, I'm also not aware of a good way to get a list of the intrinsics - maybe rustdoc's JSON output?

[valadaptive]

I think #108 mostly solves this but not completely, and as you said, it seems like it'd have a compile time cost and maybe even a runtime cost as well. Having two different codepaths, that generate two different things, for cfg(test) and cfg(not(test)) seems fraught with peril.

Safety mostly aligns with target feature support, but not completely. Load/store intrinsics will always be unsafe because they work with raw pointers, for instance. (Although I don't think we use any here yet.)

I'm still curious how the lists of intrinsics were generated for core_arch. However that was done, I think we can reuse it for this.