Add cast to and from GUID

[lynzrand]

This pull request adds casts to and from GUID, as well as tests for them. The cast preserves ordering but not byte arrangement.

The added items are:

• Ulid.ToGuid()
• explicit cast to Guid ((Guid)ulidInstance)
• Constructor new Ulid(guid)

This cast is not the same as NUlid.ToGuid()!

Notes

According to Documentation on Guid type, comparison between Guids is done as the following:

• Compare the first 4 bytes as a little-endian integer
• Compare the next 2 bytes as a little-endian integer
• Compare the next 2 bytes as a little-endian integer
• Compare the remaining bytes byte by byte

To preserve ordering, we must encode the first 8 bytes as little-endian integers, thus changing the byte arrangement.

[neuecc]

Guid and Ulid is completely different structure. If Guid -> Ulid, Ulid's timestamp is completely random. I don't think it makes sense. But if conversion is needed, Unsafe.As <Guid, Ulid> (ref value) Will convert it.

[lynzrand]

My purpose of this pull request was that, as many database support storing Guid (uuid) data type as an int128 value, we can convert this Ulid value into Guid and use as database primary key, while also preserving order so we can still sort the database key according to time. The same thing applies to networking, etc. as Guid is more widely used and supported than Ulid.

Using a Guid as a Ulid is not my purpose.

[neuecc]

Thanks, I've understood. Surely it is useful. ToByteArray's allocation is not good so require to rewrite code, but this feature, I should add.

[lynzrand]

ToByteArray's allocation is not good so require to rewrite code

I was hesitant on that piece of code too. Should I assume the memory layout described in the current library code's code is true for every system and build upon that?

[lynzrand]

Made a version using stackalloc spans to avoid allocation, assuming all implementations use the same Guid memory layout as the current code.