HuffmanTable* stuff needs an overhaul

[LebedevRI]

It's still too tightly coupled.
There are two things there:

1. Generating Codes/Symbols as specified by JPEG spec
2. Using some symbol table* to perform decoding
   It isn't necessary that said symbol table actually contains Huffman Codes as per JPEG spec,
   it only needs to satisfy the rules*

• strict total ordering, no two codes have the same prefix

[LebedevRI]

Some more unstructured minddumps, after staring at all that code for some time:

• There are three ways to acquire code symbols:
  • The "smart" algo like in AbstractHuffmanTable::generateCodeSymbols()
  • The obviously-correct algo as in HuffmanTableTree
  • They could be pre-generated and provided
    • I strongly suspect VC5 codes fall in this category.
      They can't be decomposed into nCodesPerLen+codeValues,
      because while those seem to be correct code symbols (no two codes have the same prefix),
      IIRC they aren't properly "sorted", i.e. the algo used for the symbol generation is different.
• All these HuffmanTable implementations strongly assume that value is a bit length.
  • Thus, they strongly insist that said value should be less than 16
    This assumption doesn't hold for:
    • CRW
    • Nikon Lossy-After-Split
    • VC5
  • BUT they already have a mode when they only decode the value (decodeLength())

It seems to me there are more layers of abstractions that are missing:

• The base class AbstractHuffmanTable should be templated on a templated CodeSymbol:
  • variant 1 - current "LJPEG":

    ushort16 code;   // the code (bit pattern found inside the stream)
    uchar8 code_len; // the code length in bits, valid values are 1..16

  • variant 2 - "VC5":

    ushort32 code; // VC5 max code length is 26
    uchar8 code_len;

• Given that we can't always just always call the setNCodesPerLenght(), it seems
  there should be a base class that would handle the generation of code symbols,
  with two options being available in API:
  • Generate the symbols from nCodesPerLenght
  • Use provided vector of pre-generated symbols.
• All the HuffmanTable impls shouldn't have a fullDecode param to setup() / decode(),
  which specifies whether value is length to get and sign-extend, or just some value, but instead
  that should be a template param over the whole HuffmanTable{LUT,Lookup,Tree} class.
  And more importantly, that template param should not be just a boolean, but yet another
  class-to-help-with-abstractions.
• HuffmanTableLUT should too be templated even further.
  It is not nice just how much logic of that LUT is hidden/scattered through that class.