Use a better architecture for Random UUIDs

[anthony-arnold]

The current way AdaID does randomness is messy.

It's - we have better ways for handling RNG in software.

I'd like to make the interface for Random UUIDs more flexible. This could include an interface for client code providing:

• own random integer,
• own generator,
• using a default generator without the need to seed it.

[skinkade]

Taking a look at the common practices of other languages' standard libraries and typically-used UUID libraries:

Language	Reference
C	https://linux.die.net/man/3/uuid_generate
C++	https://www.boost.org/doc/libs/1_85_0/libs/uuid/doc/uuid.html#boost/uuid/random_generator.hpp
C#	https://learn.microsoft.com/en-us/dotnet/api/system.guid.newguid?view=net-8.0
Go	https://github.com/google/uuid/blob/master/version4.go
Java	https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html#randomUUID--
JavaScript	https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID
Python	https://github.com/python/cpython/blob/3.12/Lib/uuid.py#L723-L725
Rust	https://docs.rs/uuid/latest/uuid/struct.Uuid.html#method.new_v4

All of the above default to or exclusively use the system CSPRNG to grab 16 bytes, then set the variant and version. The system_random crate could work well here instead of directly using /dev/urandom and seeding a generator.

Several of the above allow creating a UUIDv4 from an existing array.