Users should #include <hb.h> (or hb-ft.h, hb-glib.h, etc), but
never things like hb-shape.h directly.  This makes it easier to
refactor headers later on without breaking compatibility.

Fixes Mongolian shaping issue:
https://bugs.freedesktop.org/show_bug.cgi?id=45695

Fixes 200 failures out of previous 4290 cases in the OO.o Indic
dictionary (of ~16000 entries).

This is what old HB does.  Morever, fixes rendering with Win8 malgun
font.  The Win7 version doesn't compose with either Uniscribe nor HB,
but Win8 version works as expected, like Uniscribe, with this change.

Lets call Hangul done for now.

I couldn't measure significant performance gains out of this; maybe
about 5% (with one million Malayalam strings).  Still, not bad.
But reminds me that optimizing this codebase without profiling first
is simply not going to work.  Oh well...

As reported by Jonathan Kew on the list.

As reported by Jonathan Kew on the list.

Not hooked up yet.

That's not in the OpenType spec, but it's what MS and Adobe do.

Previously, we were NOT actually recomposing Hangul Jamo.  We do now.
The two lines in:

test/shaping/texts/in-tree/shaper-default/script-hangul/misc/misc.txt

Now render the same with the UnDotum.ttf font.  Previously the second
linle was rendering boxes.

We can also start applying OpenType Jamo features later.  At this time,
I have no idea how the 'ljmo', 'vjmo', 'tjmo' features are supposed to
work.  Maybe someone can explain them to me?

In this mode we try composing CCC=0 with CCC=0 characters.  Useful for
Hangul.

No logical difference so far.

Composed, and decomposed, of the same text.

In preparation for Hangul shaper.

This is the most convenient way to browse scripts.

Cross-checked with Mark Davis's spreadsheet at http://goo.gl/x9ilM