to_bytes_le documentation is misleading

[Fearghal-Des]

The implementation of to_bytes_le appears to follow the mixed endian Microsoft GUID format mentioned in the endianness section of the wikipedia page : https://en.wikipedia.org/wiki/Universally_unique_identifier:

An exception to this are Microsoft's variant 2 UUIDs ("GUID"): historically used in COM/OLE libraries, they use a little-endian format, but appear mixed-endian with the first three components of the UUID as little-endian and last two big-endian. Microsoft's GUID structure defines the last eight bytes as an 8-byte array, which are serialized in ascending order, which makes the byte representation appear mixed-endian.[23] For example, 00112233-4455-6677-8899-aabbccddeeff is encoded as the bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff

The documentation on the to_bytes_le method doesn't provide any information on how bytes are rearranged. As a result, I assumed that the byte order would be reversed from big endian:

The bytes will be flipped to convert into little-endian order. This is based on the endianness of the UUID, rather than the target environment so bytes will be flipped on both big and little endian machines.

It would be very useful if the documentation gave a brief explanation of how endianness works for UUIDs.

[KodrAus]

Thanks for the suggestion @Fearghal-Des 👍 This would definitely be good to better call out in the docs.