Before, the IntType::cmp functions providing this and was truncating
the hb_codepoint_t to 16bits before comparison.  I have no idea how
this was never discovered, and I'm too lazy to try to reproduce this
with Pango (which uses non-16bit codepoint numbers for missing glyphs).

I was hoping to see a nice speedup, but it resulted in a very minor one.

Shouldn't be needed.  I have a hard time imagining this breaking any
legitimate use case.

Needed some rework of Extension table.  Hopefully I got it right, and
the new template usage doesn't break any compilers...

No functional change right now.

This makes a lot of code safer.  We only try modifying the object in one
place, after making sure it's safe to do so.  So, do a const_cast<> in
that one place...

Can be further optimized, but I think I didn't break anything.

Saves another 3% off Roboto shaping.

Towards reducing the cost of initializing skippy_iter()

Has no functional effect since reject was never used with
match_glyph_data.

Currently:

  - Initializing skippy is very expensive,

  - Our lookup accelerator (using set-digests) can be very ineffecite,

As such, we end up many times initializing skippy but then failing
coverage check.  Reordering fixes that.

When, later, we fix our accelerator to have truly small false-positive
rate (for example by using the frozen-sets), then we might want to
reorder these checks such that we wouldn't calculate coverage number
if skippy is going to fail.

This shows a 5% speedup with Roboto already.

I experimented with replacing use of hb_set_digest_t with this new
hb_frozen_set_t, hoping to get a huge speedup for busy lookups
(like kern lookup in Roboto), but I only got 6% speendup in Roboto
and 4% in NotoNastaliqUrduDraft :(.

Fix build with MSVC on CE