Add AArch64 RNDR register backend

[newpavlov]

AArch64 platforms from version Armv8.4 onwards may implement FEAT_RNG. FEAT_RNG introduces the RNDR (and RNDRRS) register, reading from which returns a random number.

Add support for using the RNDR register as a backend for getrandom. The implementation is added as rdrnd opt-in backend.

Currently, runtime detection of FEAT_RNG relies on the Linux Kernel's MRS emulation, on other targets users have to either enable the std crate feature, or the rand target feature at compile time.

Based on #494, but does not include fallback to OS API if RNDR is not available for consistency with the RDRAND backend.

[mrkajetanp]

Imo we should still keep the OS fallback variant, RDRAND is way more commonly available than RNDR is at this moment. Not having a fallback variant pretty much just restricts this to use-cases where someone knows 100% which specific CPU they're building for. I can post the updated PR after the weekend if you'd like.

Also, instead of relying on the mrs emulation we could just make that backend depend on the std feature and use the std::arch runtime feature detection macro.

[newpavlov]

Imo we should still keep the OS fallback variant

The problem is that OS fallback will be OS-specific, e.g. in your PR it was Linux-only. I don't think we should duplicate the cfg-if from lib.rs.

restricts this to use-cases where someone knows 100% which specific CPU they're building for

I think this is fine. Otherwise, users should just use the "portable" OS API. With the fallback we just make crate's footprint bigger and code more convoluted. Also, potential performance improvements are not so clear cut, since IIUC access to RNDR register may be emulated using traps, which likely to be slower than just calling the getrandom syscall (especially with the vDSO optimization).

Note that the custom backend still allows users to provide their own implementation, so it should be sufficient for an escape hatch.

I can post the updated PR after the weekend if you'd like.

Personally, I don't think that we need a "RNDR with Linux fallback" backend. But it could be useful for input from potential users and other maintainers, so it may be worth to have such PR. The fallback probably should just use libc::getrandom without the second layer of file fallback.

the std feature and use the std::arch runtime feature detection macro

Yes, I also thought about doing it.