Refactor the main cfg_if in backends.rs

[bushrat011899]

Objective

Within backends.rs, the selection of a backend is controlled by a single monolithic cfg_if statement. In my opinion, it's quite confronting to work on in its current form, as the ordering of branches is highly consequential and effectively spans the full ~200 lines of the file. Ideally, this statement would be easier to reason about.

Observations

With a bit of squinting, it's possible to perceive the cfg_if as having 3 main "chunks" (in order):

1. Overrides from getrandom_backend
2. Default backend selection
3. The compile_error catch-all to inform the user when a backend isn't available

Section 1's ordering within itself, in my opinion, does not matter. Since these flags are set by the user, it is very difficult to inadvertently have two getrandom_backend's selected at the same time. Even if such a case occurred, I don't believe getrandom can reasonably infer what the user meant anyway. Section 3 is also a single else branch, so its ordering is trivially inconsequential.

Section 2 is where ordering currently matters. For example, under target_os = "linux", we select (in order):

1. linux_raw if target_env = ""
2. linux_android_with_fallback if the Linux kernel version may be older than 3.17
3. getrandom otherwise

But branches 2 and 3 are intermingled with other configurations which may use those backends, spreading the Linux backend selection logic over many lines of code (made worse by the complexity of the configuration statement detecting legacy versions of the Linux kernel).

I believe this arrangement is specifically chosen for a combination of evolution (backends added over time, slowly increasing the complexity of the logic), and a desire to reduce the number of locations where a mod backend; statement is used.

Solution

• Refactored section 2 to exclusively select based on target_os, allowing its ordering to be inconsequential.
• Where multiple backends for a particular target_os could be selected (e.g., linux), moved the ordered selection into an inner cfg_if statement. This matches how wasi backends were selected based on target_env, so there is precedent for this style.
• Where a particular OS is only supported on certain platforms (e.g., horizon), included a specific compile_error statement to better inform the user of what went wrong and what they can do to resolve the issue.
• Replaced usage of cfg(windows) with cfg(target_os = "windows"). They are equivalent, but target_os better matches the other branches, so I believe it is easier to understand.
• Added a specific compile_error for target_os = "uefi" that calls out the opt-in efi_rng backend.
• Removed the target_arch = wasm32 clause from the WASI branches as it is redundant.
• Created an explicit branch for target_os = "none" and target_os = "unknown". This covers cases where there is either no OS, or the OS is unknown. In this case, an inner cfg_if is added to switch on the target_arch. Baremetal x86(64) and Aarch64 is supported through rdrand and rndr respectively, and wasm32 is supported if and only if wasm_js is enabled. If wasm_js isn't enabled, the existing compiler error for that situation is thrown. If the target architecture isn't one of those 4 then a specific compile_error is thrown.

Notes

• This PR adds support for baremetal x86(64) and Aarch64 just by virtue of how the selection logic is now organised. That can be easily removed if it is controversial. I've chosen to leave it in as it will only be used when the OS is explicitly unknown (only used on 2 WASM targets and 1 Fortanix), or explicitly none (many targets, but currently unsupported by getrandom, so existing users are already defining a getrandom_backend and will be unaffected).
• This PR's utility is subjective as it's largely a stylistic change. In my opinion, this is easier to read and reason about.
  • Gaps in support are now much clearer (e.g., Nintendo Switch now has an explicit compiler error)
  • Complex ordering is now localised to no more than 3 branches within a much smaller cfg_if.
• I started working on this while experimenting on a 1.0 release of my own crate crossfig, which I've designed to try and make managing complex configurations easier. I chose getrandom to play with as it contains one of the most complex cfg_if statements I'm aware of.

[bushrat011899]

I'm not really sure why Test / iOS Simulator failed, I don't believe it's because of this PR, but I think I'd need some assistance if this PR did somehow cause the issue.

[newpavlov]

The current state is fine and I don't think it needs LLM-based refactorings.

[bushrat011899]

Understood, just clarifying I don't use LLMs or any other AI tooling.