SE-0202: Random Unification

Storing the RandomSource as an existential in RandomNumberGenerator would probably prevent many optimizations, making it unnecessarily slow, and as source can be a reference type or value type, it's unclear how a (seedable/pseudo-) RandomNumberGenerator should be passed in order to preserve state changes between calls (should it always be inout or should all RandomSources be class-types? I'd say the latter makes most sense). Also, I guess the get methods could be called next.

Again, some concrete example use cases / projects in which the Random API could be put to actual use would quickly reveal these and many other issues/questions, as well as serving as an actual foundation for the design decisions, currently there is no such foundation except vague speculations.

It looks like a practical foundation for and evaluation of the design of the API will have to wait until after a(n essentially untested) proposed API gets approved and implemented, which seems a little backwards to me.