Binary format bikeshed: where the `typeidx` immediate is located

[alexcrichton]

Currently this proposal specifies memarg ::= flags:u32 offset:u32 typeidx:u32 when flags has bit 5 set, but subjectively I find this a bit inconsistent with other immediates-specified-by-flags. For example bit 6, implying a memory index immediate, looks like memarg ::= flags:u32 memidx:u32 offset:u32. For the acquire-release-atomics proposal bit 4 implies memarg ::= flags:u32 ordering:u8 offset:u32 (at least I'm pretty sure given my current reading of the explainer and parser).

I opened a somewhat related issue at WebAssembly/acquire-release-atomics#28 but I think it'd be a bit nicer if the flags bits had payloads present after the flags leb in increasing order of the bits. Specifically I'd propose:

;; already specified in core wasm
memarg ::= flags:u32 offset:u32                               if (flags >> 4) == 0b000
         | flags:u32 memidx:u32 offset:u32                    if (flags >> 4) == 0b100

;; added by acquire-release-atomics
memarg ::= ...
         | flags:u32 ordering:u8 offset:u32                   if (flags >> 4) == 0b001
         | flags:u32 ordering:u8 memidx:u32 offset:u32        if (flags >> 4) == 0b101

;; added by multibyte-array-access
memarg ::= ...
         | flags:u32 typeidx:u32 offset:u32                   if (flags >> 4) == 0b010

;; added by both 
memarg ::= ...
         | flags:u32 ordering:u8 typeidx:u32 offset:u32       if (flags >> 4) == 0b011

where 0b110 and 0b111 are both parse errors with this proposal (memory index + type index). The 0b011 case might be invalid for now though while this proposal isn't extended to atomics, though.

Basically though I wanted to ask: what would others think about moving the typeidx immediate to before offset:u32?

EDIT: sorry forgot to finish writing the issue title before I hit submit so the notifications sent out have a pretty bad issue title :(