Remove field/variant ordering constraints in enums/structures.

[timothee-haudebourg]

Structures and enums have a notion of order between the fields/variant that must be preserved by intersection.
This creates some issues with the layout intersection operator that becomes sometimes unpredictable, and may even throw an error for unclear reasons.

For instance, take the following definition:

type A {
	ex:prop1: A
}

type B {
	ex:prop2: B
}

type AB {
	ex:prop2: B,
	ex:prop1: A
}

type C = AB & B & A;

The intersection C is evaluated as (A & B) & AB. A & B gives the following layout:

type A & B {
	ex:prop1: A,
	ex:prop2: B
}

The order of fields is the opposite from the AB layout. Because of that, the intersection with AB fails (unaligned layouts).
Because the intersection is supposed to be associative, no matter how the C intersection is written TreeLDR will always interpret it in the same order, and it will always fail.

Because of this, I now believe trying to preserve the field ordering was a bad idea. Most of the time this information is not needed (fields could have a canonical order). In the rare case where it could be needed, we could still add a marker for it later. But without it, the intersection can be truly associative.

The same reasoning can be made about enum variants.