ESP-IDF's `esp_fill_random` is not always cryptographically secure

std currently uses esp_fill_random as random number generator on ESP-IDF. Unfortunately, Espressif's platform documentation says that

The entropy source enabled during the boot process by the ESP-IDF Second Stage Bootloader seeds the internal RNG state with some entropy. However, the internal hardware RNG state is not large enough to provide a continuous stream of true random numbers. This is why a continuous entropy source must be enabled whenever true random numbers are required.

with "continuous entropy sources" referring to the radio system and an internal entropy source. And thus

the output of the RNG should be considered as pseudo-random only.

without these sources being enabled. Unfortunately, there does not appear to exist an API for detecting whether said continuous entropy sources are enabled.

Ideally, Espressif would implement their own CSPRNG in their HAL, and properly seed it in the bootloader (or at the first call to esp_fill_random). But until that happens, I see three ways to deal with this on our end:

1. Disable random data generation on ESP-IDF entirely, until Espressif fix their API.
2. Provide a certify_rng_available (name bikesheddable!) function in std::os::random, and only call esp_fill_random if that function has been called.
3. Call it a day, as our documentation already states that: "If security is a concern, consult the platform documentation below for the specific guarantees your target provides.". I'm not a fan of this "solution".

CC @ivmarkov @MabezDev @SergioGasquez

Also see:

• The corresponding getrandom issue: https://github.com/rust-random/getrandom/issues/397
• The Zulip thread where this came up: #t-libs > Split a `SystemRandomSource` out of `DefaultRandomSource`

Start at std's ESP-IDF use of esp_fill_random and review the Espressif random API documentation linked in the issue. Compare the three proposed policies, including whether std::os::random needs a certify_rng_available entry point; done requires an agreed security guarantee and an implementation or documentation change that matches it.