Visual C++ 2005 (8.0):
- _MSC_VER: 1400
- MSVCRT_VERSION: 80

* [DOC] Clarify differences between Kernel.rand and Random.rand

* `Kernel.rand` converts the `max` Float argument to Integer and returns Integer values
* `Random.rand` preserves the `max` Float argument and returns Float values
* Added examples demonstrating the behavioral differences

We recently converted this to be WB_PROTECTED, but missed some locations
the seed was set.

This is a little bit confusing because as far as I can tell some of the
seeds are set in Ractor local storage, and others on actual objects.

First try dedicated system calls, such as `getrandom` or `getentropy`,
next possible libraries, then fallback to `/dev/urandom`.

This is a follow-up to commit b120f5e38d9c (avoid fork-unsafe arc4random
implementations, 2018-09-04).

Avoid defining a no-op fill_random_bytes_syscall() if arc4random_buf(3)
exists, but we are unsure if it is fork-safe. Check for other options
instead. IOW, see if getrandom(2) is available.

glibc 2.36, released in 2022, started to provide arc4random_buf(3) on
Linux. This causes fill_random_bytes_syscall() to use neither of them
and makes Random.urandom solely rely on getentropy(3) via
fill_random_bytes_urandom().

While the glibc implementation is safe, I did not add it to the list
because using getrandom(2) directly is preferable on Linux.

If this is not a system call, then it is using getrandom (which would
have been tried already), and cannot be used as a replacement for the
random devices.

`len` is always at least 1 here.

When loading a crafted marshal data of Random, a pointer to an illegal
address was created. I don't think there is any harm since the data is
normalized before access, but just to be safe, I add a check to make it
an error.

Do not retry `fill_random_bytes` in `Init_RandomSeedCore`, just after
it failed first.

In other places, `rand_init_default` and `random_seed`, no more tweeks
needed once it succeeded