lar can accept multiple sizes as well (wlx), like lsl.  When using
autosize it's important to look at the destination operand first;
when it's a register that one determines the size, not the input
operand.

Those two insn types are nicer to handle as operand types, because
the pressure for bits on instr_type is higher than for operands.

Now we can express prefixes with 0x0fxx opcodes we can correct the
movq mem64->xmm opcode, and restrict the movq xmm->mem64 movq to
not invalidly accept mmx.

Now that we can store prefixes even for 0x0fXX opcodes we can remove
the OPC_D16 bit.

Disjoint instruction types don't need to be a bit field, so
introduce an enumeration (3 bits).  Also the 0x0f prefix can
be expressed by a bit, doesn't need a byte in the opcode field.
That enables to encode further prefixes still in 16 bit.
To not have to touch all insns do some macro fiddling filtering
out a 0x0f byte in the second position.

In particular those that are extensions of existing mmx (or sse1)
instructions by a simple 0x66 prefix.  There's one caveat for
x86-64: as we don't yet correctly handle the 0xf3 prefix
the movq mem64->xmm is wrong (tested in asmtest.S).  Needs
some refactoring of the instr_type member.

There were two errors in the arithmetic imm8 instruction.  They accept
only REGW, and in case the user write a xxxb opcode that variant
needs to be rejected as well (it's not automatically rejected by REGW
in case the destination is memory).

Two things: negative constants were rejected (e.g. "add $-15,%eax").
Second the insn order was such that the arithmetic IM8S forms
weren't used (always the IM32 ones).  Switching them prefers those
but requires a fix for size calculation in case the opcodes were
OPC_ARITH and OPC_WLX (whose size starts with 1, not zero).

Use OPC_BWLX and OPC_WLX in i386-asm.h and x86_64-asm.h to
reduce number of differences between both.

This code was inactive since a long time (and was deactivated because
it was wrong to start with) and just clutters the sources.  Remove
it.