QCRAM opcodes with non-byte-aligned string literals

[MikeBishop]

Based on #1141 and sparked by a comment on that PR that I'd like to discuss separately. There are effectively four instructions in a table update:

1. Insert with static table name reference
2. Insert with dynamic table name reference
3. Insert with no reference
4. Duplicate (a.k.a. insert with name+value reference)

#1141 follows HPACK's lead in treating insert as a single instruction with internal flags describing different possible references. That leads to effectively using two-bit prefixes for (1)/(2-3), a sentinel value in the index to differentiate (2)/(3), and (4) gets a single-bit instruction code even though it's the least common. This PR treats them as four instructions and uses two-bit prefixes for each.

The impact of this is break-even for literals which reference a name from the header table. The benefit is that you save a byte on almost every header which is inserted without a name reference.

The cost is:

• "Roughly 15 minutes of hacking (to add the extra argument)" in @martinthomson's estimation
• An extra byte required to duplicate entries which are at indexes 64-127, modulo Duplication can use different indexing #1128.
• It's no longer as simple to look at one bit and say that bit has a consistent meaning

[martinthomson]

Without Name Reference

[martinthomson]

Almost a bike shed: invert the second bit here. Then you can reasonably say that you are describing 11 (insert with static name reference), 10 (insert with dynamic name reference), 01 (insert with new name), 00 (duplication).

[MikeBishop]

I'm not wholly sure that makes a difference, but I suppose there's an argument to be made that '00' is the "unique" one.

[MikeBishop]

Having separately discussed bringing back table size change, there are now five instructions, so "00" represents "uncommon things" with a third bit to differentiate duplicate versus size change. Purely by coincidence, that means size change is now identical to the HPACK instruction.