Since Linux 3.17, the syscall `getrandom` can be used to generate bytes from the same entropy source as `/dev/urandom`. This makes it suitable for cryptographic random number generation, something our Guid generator needs.

If `getrandom` is not available because the LibC provided is too old - or if the syscall itself is not available, it will fall back to the previous method of reading from `/dev/urandom`.

`EPERM` is treated like `ENOSYS` - some older Linux kernels returned this when the syscall is not available. The syscall can also be blocked by seccomp. That would be weird, and Docker permits it by default, but if anyone has explicitly gone out of their way to block it, it falls back to using the file descriptor mechanism.

The use of the syscall implementation instead of the file device offers some performance improvements. Anywhere from 10% to 15% in benchmarks.

This does require glibc 2.25. For non-portable builds, that's largely fine. For Microsoft builds, those are (currently) being done on Ubuntu Xenial, which has 2.23. However, it is expected that with .NET 10, the glibc floor is going to change to 2.27 with #109939. If that happens, then the Microsoft portable builds will pick this up as well.

This PR does _not_ change the user-facing `RandomNumberGenerator` that will continue to use `RAND_bytes` from OpenSSL.

| Method         | Toolchain | Mean     | Error   | StdDev  | Ratio |
|--------------- |---------- |---------:|--------:|--------:|------:|
| NewGuid        | branch    | 265.1 ns | 0.24 ns | 0.22 ns |  0.87 |
| NewGuid        | main      | 304.6 ns | 0.16 ns | 0.15 ns |  1.00 |
|                |           |          |         |         |       |
| CreateVersion7 | branch    | 293.2 ns | 0.20 ns | 0.18 ns |  0.88 |
| CreateVersion7 | main      | 335.0 ns | 0.27 ns | 0.23 ns |  1.00 |