Add fast random facility.

This is a low-memory-overhead and low-cpu-overhead (per generated
bit) random number generator.  The repeat cycle is around 2**88.
Which means around 2**120 bits are available before a cycle.  Which
means that about 2**102 12-bit samples are available before repeats.

This should be more than sufficient for blob rollover purposes.
If 100 million blobs are split per second (absurdly high), then
that's about 2**27 per second.  If run for 30 years, that's
2**30 seconds.  If run across 128 CPUs, that's 2**7 CPUs.  Thus
2**(27+30+7) total samples are required before loop.  This is
2**64 which is WAAAY less than 2**88.  (And this is overly
conservative, as these generators should be one-per-thread...
so we're really much closer to 2**57, not that it matters.)

For this reason, there's no reseed code.  The cycle length of
mt11213b is significantly longer, however, it has a significantly
larger state.  One goal here is to keep the amount of state for
this generator to a single cache line.  As such, if the cycle
length is later shown to be significantly smaller than 2**48
or so, a reseed code path may need to be added.  (This is on
the assumption that the above described intensive run would
run for more than 1 million seconds, or about two weeks.)

fastRandom.h

@@ -0,0 +1,20 @@
+static_assert( __cplusplus > 2023'00 );
+
+#pragma once
+
+#include <Alepha/Alepha.h>
+
+#include <cstdint>
+
+namespace Alepha::Hydrogen  ::detail::  fastRandom_m
+{
+	inline namespace exports
+	{
+		std::uint32_t fastRandomBits( int numBits );
+	}
+}
+
+namespace Alepha::Hydrogen::inline exports::inline fastRandom_m
+{
+	using namespace detail::fastRandom_m::exports;
+}