0.0.7

Change dynamic/variable counter: 4-18bits
Add 'back off' logic: when on the 'edge', gradually reduce number of bits instead of going straight back to 4 bits.
FIX: Take the remaining lower bits from the Guid (random) instead of from the counter (constant). This increases randomness.

0.0.6

Since it is difficult to choose correct number of counter bits: change to dynamic/variable counter: 12-18bits

Changed my mind on several things:
Remove rollover guard
Change to 13bits counter
Remove timestamp adjustment forward if clock goes back in time (instead, monotony will break). RFC is lacking info about how to handle this case for Uuid v7, but from what the RFC write about Uuid v1/v6 and the clock sequence, adjusting the timestamp forward if the clock goes back, is IMO generally wrong.

Add rollover guard (initialize top bit of 26bit counter to 0)
Rename GuidInfoVersion1And6.Sequence -> GuidInfoVersion1And6.ClockSequence
PERF: reduce lock region
PERF: do not use class Random to get the 1-255 increment. Fetch it from the Guid instead (a part overwritten by timestamp).
Add FromHexString
Sql: add uuid_v7_array function. Using dbo.uuid_swap_endian(dbo.uuid_v7()) directly (two functions calls in same statement) mysteriously generate Uuid's out of order!?

Make CreateVersion7 and CreateVersion8MsSql monotonic (in same process), so remove CreateVersion7Sequence and CreateVersion8MsSqlSequence.
Change ms sql scripts to be monotonic for uuid_v7 and uuid_v8mssql (in same session).

Bitswapping was not correct for v7<->v8MsSql. bytes[6] and bytes[7] were swapped (endianess).
CreateVersion8MsSql: forgot to preserve 2 random bits in bytes[9].
Increase the counter size in sequential v7 and v8mssql from 12 to 26 bits (include all bits from 4 middle bytes).
Instead of +1 in the counter, add a random byte (1-255).