Inconsistency in argument orgering

[dr-orlovsky]

With the move to use Intel-style ordering in assembly ("destination-first ordering") we got into a quite inconsistent state:

• not all mnemonics follow this rule, with a weird mix
• ordering of the arguments in Enum code representation doesn't follow the rule
• byte serialization (bytecode) differs from the rule.

We have the following options of introducing consistency here:

• change everything to the new rule. This will break all binary compatibility and will require quite a lot of routine work to ensure nothing is missed
• revert changes to mnemonic argument re-ordering and stick to the old "destination-last" ordering rule
• leave mnemonics destination-first ordered - and the rest "destination-last" (i.e. make inconsistency systemic feature :)

I am pro second option, since a released RGB v0.10 already depends on the bytecode in AluVM, and if we use the first option, we need to fork AluVM and maintain two variants of it - one for RGB and the other one for the rest of the world.

Opinions? @6293

[6293]

I am ok with the second option. I'd say the we are not fully "destination-last" in the old version, as mentioned in https://github.com/AluVM/rust-aluvm/issues/75. So we will not achieve fully consistent ordering, but it cannot be helped because it is already on the production code.