Make all operating system assumptions explicit

[briansmith]

Right now we generally add support for operating systems by having somebody send a PR that extends the cfg logic for the use of getrandom in ring::rand with the name of that OS, and then changing build.rs to say that their operating system is "pretty much the same as Linux as far as ring needs to be concerned," effectively. Instead of saying that the OS is pretty much like Linux we need to break down what we really need from the operating system.

Instead, I propose that we make the following assumptions in the short term:

• We can always rely on #[cfg(target_feature)] for static feature detection.
• If libstd is available, then assume we can use is_x86_feature_detected/is_aarch64_feature_detected on x86/x86-64/AArch64, and we can cache the results and use the cached results all the time.
• If libstd is not available, then we cannot do dynamic feature detection at all and we should never compile any code that relies on any CPU features that aren't detected by #[cfg(target_feature)].

Then we need to deal with ABI issues if we want to use assembly files, even without dynamic feature detection. In particular, we need to know what the target ABI is. In the future, rust-lang/rust#80970 will allow us to learn this in build.rs and using #[cfg(target_abi)]. Until then, we need to create a mapping of (target_os, target_arch) to target_abi in build.rs and use it to inform our choices of whether to enable assembly implementations; by default we don't use compile any assembly implementations if the operating system's ABI isn't in our mapping.

In this way, we will be able to compile on all operating systems including "none", with only one allowlist in ring::rand. Then after #1787, and maybe some work in the getrandom crate, we can reconsider whether this allowlist makes sense.

[briansmith]

Until then, we need to create a mapping of (target_os, target_arch) to target_abi in build.rs and use it to inform our choices of whether to enable assembly implementations

Rather than have contributors patch this mapping manually, we should create some tool (script?) that extracts all this information from Rust's target definitions, since it is already there.