Disable random implementation with strong libcrypto versions

[camshaft]

Problem:

The random module is one of the more complicated components and causes most of the issues in portability.

• s2n-tls does not check if entropy_fd is still open #4324
• Fix incorrect inline assembly usage in s2n_rand_rdrand_impl #4310
• Taking ownership of OpenSSL randomness backend doesn't always work #4253
• /dev/urandom fd leaks to subprocesses #3928
• calling s2n_cleanup with no s2n_init corrupts thread-local storage #4226
• s2n_random.c crashes with invalid zero_if_forked_ptr value on x86_64 Android emulator #3066
• Pthread key resource leak #3990
• Crash on thread termination when s2n has been unloaded #3987
• s2n_random.c: memory leaks of per-thread rand state #3525
• error open urandom #3445
• Improve fork detection #3107
• Unclear on how to use s2n_cleanup from multiple threads #649

(This was just an initial search; there's probably more)

We also support linking to, for example, AWS-LC, which has a very good random implementation.

Solution:

When linking to a libcrypto backend with a strong entropy implementation, we should just use that instead of override it with our implementation. We should also avoid compiling our random implementation in this situation to remove the thread locals and global file descriptors.

We'll need to decide which libcrypto implementation is acceptable to use.