Fixes https://github.com/behdad/harfbuzz/issues/211

What happens in that bug is that a mark is attached to base first,
then a second mark is cursive-chained to the first mark.  This only
"works" because it's in the Indic shaper where mark advances are
not zeroed.

Before, we didn't allow cursive to run on marks at all.  Fix that.
We also where updating mark major offsets at the end of GPOS, such
that changes in advance of base will not change the mark attachment
position.  That was superior to the alternative (which is what Uniscribe
does BTW), but made it hard to apply cursive to the mark after it
was positioned.  We could track major-direction offset changes and
apply that to cursive in the post process, but that's a much trickier
thing to do than the fix here, which is to immediately apply the
major-direction advance-width offsets...  Ie.:

https://github.com/behdad/harfbuzz/issues/211#issuecomment-183194739

If this breaks any fonts, the font should be fixed to do mark attachment
after all the advances are set up first (kerning, etc).

Finally, this, still doesn't make us match Uniscribe, for I explained
in that bug.  Looks like Uniscribe applies minor-direction cursive
adjustment immediate as well.  We don't, and we like it our way, at
least for now.  Eg. the sequence in the test case does this:

- The first subscript attaches with mark-to-base, moving in x only,
- The second subscript attaches with cursive attachment to first subscript
  moving in x only,
- A final context rule moves the first subscript up by 104 units.

The way we do, the final shift-up, also shifts up the second subscript
mark because it's cursively-attached.  Uniscribe doesn't.  We get:

[ttaorya=0+1307|casubscriptorya=0@-242,104+-231|casubscriptnarroworya=0@20,104+507]

while Uniscribe gets:

[ttaorya=0+1307|casubscriptorya=0@-242,104+-211|casubscriptnarroworya=0+487]

note the different y-offset of the last glyph.  In our view, after cursive,
things move together, period.

No effect.

Part of fixing https://github.com/behdad/harfbuzz/issues/211

Right now the position_finish_advances() is empty.  To be used for
spacing attachments proposal later.

Will do nothing.  Just useful for merging two functions.

Differentiate, using new attach_type().

No behavior change.  Preparing to unify how cursive and mark attachments
work.

Apparently class=0 is used for ClassDef1.  See:
https://github.com/adobe-type-tools/afdko/issues/90

I'm starting to really like how free these new scratch_flags are.

Fixes https://github.com/behdad/harfbuzz/issues/139#issuecomment-146984679

This is a fix on top of the previous issue fixed in
c917965b.

This was caught by "libFuzzer" testing.

Not functional change (expected!).

Fixes possible invalid read of two bytes.

Reported by Behzad Najjarpour Jabbari, Secunia Research.

See thread "Issue with cursive attachment" started by Khaled.
Turned out fixing this wasn't as bad as I had assumed.  I like the
new code better; we now have a theoretical model of cursive
connections that is easier to reason about.

In anticipation for upcoming fix for bug reported by
Khaled in thread "Issue with cursive attachment".

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()

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.

Roboto has glyphs (like 'F') that have 200 kerning pairs.
Add a handcoded bsearch instead of previous linear search.

This doesn't show much speedup though, apparently we spend the
bulk of the time somewhere before here.