Handling endian Uuids

[kinggoesgaming]

Based on #461 by @DianaNites

---

Lack of proper little-endian support, which was partially removed?

This also plays into my confusion, theres Uuid::(to/from)_fields_le and Uuid::(to/from)_u128_le, but not Uuid::from_bytes_le? Theres Uuid::as_bytes but not Uuid::as_bytes_le?

This in particular is complicating things for me, as the Uuids I want to handle are "inspired" by Microsoft and stored mixed-endian. (Also, something I encountered when switching the bytes myself is Uuid::get_version_num returning 14 instead of 4, so those specific last few bits may need special handling?)

[KodrAus]

I think missing from_bytes_le and to_bytes_le may be an oversight. We could support them, by internally treating the integers encoded as bytes as being little endian (this is different from u128, where we flip the whole buffer).

[KodrAus]

Coming back to this, I don't think from_bytes_le or to_bytes_le really make sense, because there's nothing to flip. Our current _le methods assume any integer inputs need to be flipped, but in from_bytes and to_bytes there aren't any integers in the input or output.

[KodrAus]

Just coming in through some triage. I think our _le methods are in good shape now and have some reasonable documentation that demonstrates how they work.

[KodrAus]

Coming back to this, I don't think from_bytes_le or to_bytes_le really make sense, because there's nothing to flip.

Coming back to coming back to this, I think this isn't a very helpful stance. There is of course something to flip in from_bytes: the fields encoded in the buffer. So in #544 I've added from_bytes_le and from_slice_le methods that take care of this for you.

[dfaust]

Since we now have from_bytes_le, I think we should also have to_bytes_le.
If you want me to write a PR, let me know.

[KodrAus]

Hi @dfaust 👋

This sounds reasonable to me!