Better support for non-{glibc, bionic, musl, uclibc} libcs, e.g. LLVM libc, on Linux

LLVM libc always has getrandom, based on what I infer from https://libc.llvm.org/platform_support.html, so no dynamic detection of any kind is necessary. Unfortunately, AFAICT there is no way to detect whether the user will be trying to link to LLVM libc.

For now, LLVM libc users will need to set cfg getrandom_backend="linux_getrandom".

Perhaps we should change the logic so that when the target_env doesn't indicate glibc ("") or uclibc ("uclibc"?), then we should assume that we can statically link the getrandom function, call getrandom() without any dlsym, and then if it fails with ENOSYS (or whatever we currently check), then fall back. musl libc would get used to test this. I think any newer alternative libc for Linux is likely to target modern Linux versions.

OTOH, people who prefer a more "pure" Rust experience would probably prefer the raw syscall backend.

In the case of users likely to use LLVM libc, I suspect they would prefer to have the option to forbid raw syscalls from libraries outside libc when practical. So, I think it makes sense to make the default be "assume getrandom() if not glibc or uclibc" and let people who want the more pure Rust experience opt into using the raw backend.

Start with the linked LLVM libc platform-support page and the existing cfg getrandom_backend selection, especially the linux_getrandom path. Compare the current getrandom()/dlsym behavior with the raw syscall fallback; done requires a decided default and opt-in behavior for alternative Linux libcs, along with validation using musl.