Fix bad registration, mul_t1 is 16-bit
Replace linked list decode with lookup tables

The original (horribly inefficient) instruction decode simply walked a list
of all known instructions until it found a match (actually, it was worse
than that: once a match was found it would walk the remainder of the list
to verify no other matches were found so that ambiguous (incorrect) opcode
registrations could be caught).

The new mechanism builds four lookup tables, which are selected from based
on the top 5 bits of the instruction:
  o 11101: 32-bit instruction table 1
  o 11110: 32-bit instruction table 2
  o 11111: 32-bit instruction table 3
  o default: all 16-bit instructions

These tables are all 256 elements large. The 16-bit table is keyed on the
top 8 bits of the instruction (15-8). The 32-bit tables are keyed on the
top 8 most significant bits after the table selector (26-19). The tables
point to linked lists of instructions that could match. Ambiguity results
when lesser significant bits are required to uniquely identify different
instructions. The following histogram of all currently supported
instructions gives some intuition for the distribution of encodings:

hist16        0:  39, 1: 205, 2:  4, 3:   2, 4:  5, 5:  1, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0
hist32_11101  0: 186, 1:  54, 2: 12, 3:   2, 4:  0, 5:  0, 6: 2, 7: 0, 8: 0, 9: 0, 10: 0
hist32_11110  0:   0, 1:   0, 2:  0, 3: 145, 4: 75, 5: 27, 6: 8, 7: 0, 8: 0, 9: 0, 10: 1
hist32_11111  0: 192, 1:  45, 2: 14, 3:   3, 4:  2, 5:  0, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0

Some observations:

  Bucket 0 represents encodings that the simulator doesn't have an
  implementation for.

  The 16-bit encodings are not as sparse as they look. Once you account for
  the blank spaces that correspond to the 32-bit markers: 11101xxx, 11110xxx,
  and 11111xxx -> 24 unusable encodings, there are only 15 holes, most of
  which can be accounted for in core/operations/missing.txt.

  The 11110 family of 32-bit instructions requires more depth to specify and
  would likely benefit greatly from a nested set of tables.

Overall, this implementation probably didn't buy _that_ much in practice,
but it's a step in a better direction.