Guid handling does not account for endianness

[JoshLove-msft]

          > Which would confirm your hunch @KrzysztofCwalina because that encodes big endian and reads big endian in the read methods. So we would always hit the ToArray case 😭

My understanding is that TryRead should only be used for little endian, not that it would return false on big endian. This means that the current code could end up reversing the lock token if the client machine is actually big endian. Using the Guid constructor handles both cases at the cost of us needing to allocate always. We can do an endian check ourselves to only use TryRead for little endian to avoid the extra allocation.

Re: the AMQP lib handling that could cause issues now that we no longer have full control over the machine where the ReceivedMessage is serialized. Since we are serializing the received message as part of this PR, we should probably file an issue so that the AMQP lib has handling for endianness.

Originally posted by @JoshLove-msft in Azure/azure-sdk-for-net#33682 (comment)

[JoshLove-msft]

azure-amqp/src/Encoding/AmqpBitConverter.cs

Line 374 in 0c4cf8a

public static unsafe void WriteUuid(ByteBuffer buffer, Guid data)

should not assume the endianness of the machine.

[xinchen10]

Fixed in 2.6.2