for now

rep_any will get speculated `false` quite quickly, whereas checking if
the opcode is a string instruction will be costly no matter what. in the
rare case rep_any is true, i don't care how costly displaying the
instruction is - string instructions are relatively rare, and rep movs
is typically not more than one instance when it shows up.

the arms of the match in regspec_label referenced tables that were not
const. consequently, they would be rebuilt when reached, every time the
match is incanted. this holds through even when regspec_label is
inlined.

each arm could be a const array for a small and easy change, but to
avoid the indirect dispatch on spec.bank i've reorganized register names
into a single const array and selected values for `RegisterBank` such
that indices into that array can be formed.

for my next trick, i may make `REG_NAMES` a `*const u8`, with indices
  picking offsets into the table - 8-byte offsets might do? this should
  compact down size a little more by removing a pointer and size qword
  for each string.

likely operands are now also required to have contiguous special cases
0..31. this is to avoid generating a massively sparse jump table for no
reason twice - once for unlikely_operands is quite enough as-is.

this will undoubtedly be a wildly annoying maintenance burden. if this
pans out (initial expiriments suggest it might) then maybe a macro will
do...

This reverts commit 21cc850afc108c147871c70240eda62ad13f34e0.

This reverts commit 23cbcb390c723c4c39113ce93ccff89308b6623c.