just report it having one operand...

new `does_not_decode_invalid_registers` fuzzer found other bugs! the
384-bit accesses for 128b keylocker instructions are an
otherwise-unknown size and had a memory size of `BUG`. they are not
bugs. give the memory size a real name.

registers `al`, `cl`, `dl`, and `bl` could have two different
representations - with `rex.w` and without. these two forms of `RegSpec`
would not compare equal, nor has the same, so for code relying on
`RegSpec` to faithfully represent a 1-1 mapping to x86 registers, these
synonyms would introduce bugs in register analysis.

for example, in `yaxpeax-core`, this would result in instructions
writing to `rex.w al` not being visible as definitions for a future
read of `!rex.w al`.

fix this in `x86_64` code, add new test cases about the confusion,
adjust register names to make this situation more clearly a bug, and
introduce two new fuzz targets that would have helped spot this error.

* the first four 1-byte registers, `al`, `cl`, `dl`, `bl`, can be
  constructed in two ways that produce "identical" `RegSpec` that are..
  not.
  e.g. `RegSpec::al() != Regspec::rb(0)` even though
  `RegSpec::al().name() == RegSpec::rb(0).name()`.

  this corrects the `rb` constructor at least, but instructions like
  `4830c0` and `30c0` still produce incompatible versions of `al`.

* also fix register numbering used explicit qword-sized RegSpec
  constructors, r12 and r13 used to produce r8 and r9