/*
Package uuidx intends to supplement [github.com/google/uuid].

# Microsoft GUID Shenanigans

The following functions are provided to deal with [Microsoft's incompetence]:

	* [DetectMsGuid] (a confidence'd determination if a UUID is a Microsoft GUID or not)
	* [IsFlippedEndian] for flipped-endian [uuid.UUID] comparison (e.g. a is the Microsoft-flipped-endian version of b)
	* [IsMsGuid] (wraps [DetectMsGuid] and returns true if confidence is reasonably strong that it's a Microsoft GUID)
	* [IsRfc] (the inverse of IsMsGuid, but also checks for strict RFC compliance and returns which RFC)
	* [MsGuidToUuid] (explicitly convert/ensure a GUID/UUID is likely a UUID)
	* [ToggleUuidMsGuid] (blindly flip the endianness of selected byte ranges for MS GUID <-> UUID conversion)
	* [UuidToMsGuid] (explicitly convert/ensure a GUID/UUID is likely an MS GUID)

Microsoft, in their typical insanity, uses a proprietary UUID format (usually referred to as the "Microsoft GUID Format"
or "Mixed-Endian Format").

Normally for, for example a UUIDv4, it's structured as thus per RFC 9562 [§ 5.4] (which obsoletes RFC 4122 [§ 4.4]):

	       A               B               C               D                E
	HEX(BE(uint32))-HEX(BE(uint16))-HEX(BE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))

(where <BE> is big-endian packing).

However, thanks to Microsoft we can't have nice things. They decided to completely ignore the standard, and
instead keep D/E as big-endian *but use little-endian* for A through C inclusive:

	       A               B               C               D                E
	HEX(LE(uint32))-HEX(LE(uint16))-HEX(LE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))

"Surely that had SOME reason to do that," you may say to yourself, "they wouldn't make some arbitrary formatting
change from a standard just because."

You would be wrong. To my knowledge, they have never provided any technological justfification to this insanity,
and now it's infected its way into a slew of other technologies they've had their grubby little hands involved in
(e.g. UEFI). And it's of course too late to change.

So anyways here's a library to make dealing with Microsoft's hubris a little easier.

# Validation/Verification

Aside from trying to address Microsoft silliness, there are some additional functions:

	* [Equal] for [uuid.UUID] comparison
	* [IsMaxUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.10] UUID)
	* [IsNilUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.9] UUID)
	* [IsValid] (If an RFC can be considered safely conformant to RFC spec)

# Future Incorporation/Deprecation/Obsolescence

Worth keeping an eye on are:

	* https://github.com/google/uuid/pull/192
	* https://github.com/golang/go/issues/62026
	* https://github.com/golang/go/issues/76319
		(generally it's a bad idea for an API addition overall, but some good ideas were raised)

Some of these additions may deprecate/obsolete components of this package.
I'll try to keep them around but mark as deprecated as they are (if they are),
but I make no concrete promises - I hate making new major releases in Go's
[silly module architecture] even more than I do keeping old deprecated code around.
So caveat emptor.

[Microsoft's incompetence]: https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid
[§ 5.4]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.4
[§ 4.4]: https://datatracker.ietf.org/doc/html/rfc4122#section-4.4
[§ 5.9]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.9
[§ 5.10]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.10
[github:google/uuid#192]: https://github.com/google/uuid/pull/192
[silly module architecture]: https://go.dev/doc/modules/major-version
*/
package uuidx