Some operands reordering in serialization

[jeanmon]

After some analysis on the addressing resolution and bytecode decomposition (rather gluing), we expect relations to be simpler if we systematically put the address operands just after indirect byte and any immediate values at the end.

This entails the following modifications:

• CAST_8 and CAST_16: move tag at the end

• GETENVVAR: Move immediate (env variable value UINT8) to the end

• JUMPI: move jumpDst (UINT32) to the end

• SET family opcodes: move address just after the INIDRECT, then the order is: INDIRECT8, ADDRESS, TAG, immediate

• GETCONTRACTINSTANCE: move enum (UINT8) after the addresses

• DEBUGLOG: move message_size at the end (deserialisation layout sizes does not change, but the order of arguments in the serialisation do)

[fcarreiro]

I don't think TAG needs to be moved, because it's not one of the operands, it's separate (just like ind) and doesn't ever need resolution. We only need to move immediates I think. (for addressing)

[jeanmon]

@fcarreiro For SET, the immediate is before the address which are both after TAG. We have to move the address anyway so I would directly place it before the tag because I expect some simplified equations in byte code decomposition if the operands are placed similarly to other opcodes. It is clearly not a blocker but would be nice if work is moderate.

For CAST, the same reasoning apply. What I expect by putting addresses systematically before the tag, is that equations like:

O1 = selectors_1 * (B2 + B3 * 2^8)
O2 = selectors_2 * (B4 + B5 * 2^8)

I expect to have more opcodes falling into selectors_1 and selectors_2. True for TAG you need a specific equation anyway and the suggested changes will not help that, but I think it will help with the other operands