Tested that Format0 works with Kannada MN font:

$ make -j5 lib -s && HB_OPTIONS=aat ./hb-shape Kannada\ MN.ttc -u 0C95,0CC2
[kn_ka=0+1000|kn_matra_uu=0@-30,0+1345]

$ make -j5 lib -s && HB_OPTIONS=aat ./hb-shape Kannada\ MN.ttc -u 0C95,0CC2 --features=-kern
[kn_ka=0+1030|kn_matra_uu=0+1375]

Note that GPOS does the same with 'dist' feature, and applies the whole difference to the
same glyph:

$ make -j5 lib -s && ./hb-shape Kannada\ MN.ttc -u 0C95,0CC2
[kn_ka=0+970|kn_matra_uu=0+1375]

$ make -j5 lib -s && ./hb-shape Kannada\ MN.ttc -u 0C95,0CC2 --features=-dist
[kn_ka=0+1030|kn_matra_uu=0+1375]

Disable kern Format2.

Fix kerx Format2.  Manually tested this with Tamil MN font and it works:

$ HB_OPTIONS=aat ./hb-shape Tamil\ MN.ttc -u 0B94,0B95
[tgv_au=0+3435|tgc_ka=1@-75,0+1517]

 HB_OPTIONS=aat ./hb-shape Tamil\ MN.ttc -u 0B94,0B95 --features=-kern
[tgv_au=0+3510|tgc_ka=1+1592]

Still, not hooked.

Not hooked up to be called yet.

"The values in the right class table are stored pre-multiplied by the
number of bytes in a single kerning value, and the values in the left
class table are stored pre-multiplied by the number of bytes in one
row. This eliminates needing to multiply the row and column values
together to determine the location of the kerning value. The array can
be indexed by doing the right- and left-hand class mappings, adding the
class values to the address of the array, and fetching the kerning
value to which the new address points."

Sorry for the noise, downstream custom builders.  Please adjust.

Issue originally reported at http://cppfiles.com/chromium.txt .

This fixes what appears to be a copy - paste issue which causes both
KernSubTableFormat2::rightClassTable and the 'right' argument to
KernSubTableFormat2::get_kerning to go unused.

Such a headache that Windows defines UINT8, ...; Just prefix it.