.NET byte order

[bencelang]

Describe the bug
On Windows systems (and probably all systems in the by-Microsoft-family), and in .NET Guid-s are represented with the first three fields in little-endian byte order, which is the reserved Microsoft-style UUID layout mentioned in the RFC. However the variant bit is not set accordingly, so a .NET Guid cannot be detected from the byte array form automatically.

To Reproduce
Steps to reproduce the behavior:

1. Open powershell and generate a new Guid and it's byte form via running the following:

$guid = New-Guid
$guid.ToString()
$guid.ToByteArray()

2. Try parsing the byte array in a jest test:

const guid1 = Guid.fromByteArray([ /* bytes from ps output */ ]);
const guid2 = Guid.parse("<string from ps output>");
expect(guid1.equals(guid2)).toBeTruthy();
expect(guid1.toString()).toEqual(guid2.toString());
expect(guid1.toByteArray()).toStrictEqual(guid2.toByteArray());

3. See test logs

Expected behavior
Microsoft-style byte array representation is recognized and interpreted accordingly.

Proposed fix
Add an optional parameter to the fromByteArray() factory method which if set (or if set to a specific value) signals that the byte layout should be force-switched when reading the input.
Additionally, a default configuration point can be created to have this behavior as default. If a system only needs to support this layout, this reduces boilerplate code regarding the factory method.