Tweak TimeUuid generator to handle extremely fast generation cases

There were two issues with the timeuuid generator: the sequence number
was essentially a random, but should really be a monotonically
increasing value in case we run into sub 100ns requests, and the
sequence number is actually reversed in the resulting guid on little
endian machines. Added a unit test that runs through at least one full
sequence number cycle to verify that we're generating unique guids.
Fixed the generated node is to mark is as locally administered /
multicast per rfc4122.