Wrap getrandom::Error in uuid::Error for Uuid::new_v4

[CAD97]

I'm submitting a(n) refactor

Description

Resolves the TODO on Uuid::new_v4 by wrapping the getrandom::Error in uuid::Error.

HOWEVER: I don't know if this is a good idea. There's nothing directly wrong with using Result<_, getrandom::Error> here, if we're comfortable saying that new_v4 is using getrandom to get random bytes from the OS. Wrapping it in uuid::Error requires removing the Hash impl from uuid::Error, and on top of this, getrandom::Error only implements the std Error trait if the getrandom/std feature is activated. However, there is no (current) way to activate the feature only when both v4 and std features of uuid are activated, so we're stuck either requiring v4 to imply std or to not provide the getrandom error as our error's source(). Additionally, since randomness is highly reliable, this is very unlikely to fail, and the only real valid response is to halt the program. We previously just panicked if rand's thread_rng was not available, which is (roughly) equivalent to getrandom() failing. Maintaining this behavior is no worse than static quo, easier to use, sidesteps the features issue, and avoids the breaking change. Users who absolutely need to recover in the face of errors can always construct the random bytes themselves and/or just check that getrandom() doesn't fail.

Related Issue(s)

#475, as this is a breaking TODO on the API being requested to publish.

Closes #503: alternate (personally, preferred) approach to the same TODO