Work around broken automake-1.13 changes.

Fix tests build.

https://bugs.freedesktop.org/show_bug.cgi?id=71353

https://bugzilla.mozilla.org/show_bug.cgi?id=941470

Will fix by removing shape_plan->face completely.

CoreText does automatic font fallback (AKA "cascading") for  characters
not supported by the requested font, and provides no way to turn it off,
so detect if the returned run uses a font other than the requested one
and fill in the buffer with .notdef glyphs instead of random indices
glyph from a different font.

The spec and Uniscribe don't allow these, but UTN#11
specifically says the sequence U+104B,U+1038 is valid.
As such, allow all "P V" sequences.  There's about
eight sequences that match that structure, but Roozbeh
thinks it's fine to allow all of them.

Test case: U+104B, U+1038

https://bugs.freedesktop.org/show_bug.cgi?id=71947

The spec and Uniscribe treat it as consonant in the grammar, but
it's not in IndicSyllableCategory.txt, so fix up.

Test sequence: U+1004,U+103A,U+1039,U+104E

https://bugs.freedesktop.org/show_bug.cgi?id=71948

This is broken sequence according to OpenType spec, Uniscribe,
and current HarfBuzz implementation.  But Roozbeh says this
is a valid sequence, so allow it.  There are multiple
"(DB As?)?" constructs in the grammar, but Roozbeh thinks only
this one needs changing.

Test case: 1014,1063,103A

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=71949

All three are broken right now according to Roozbeh.

https://bugs.freedesktop.org/show_bug.cgi?id=71947
https://bugs.freedesktop.org/show_bug.cgi?id=71948
https://bugs.freedesktop.org/show_bug.cgi?id=71949

Based on research into latest SIL and Windows fonts, pulling in
the latest OpenType language tag proposal from Microsoft, and updating
to latest language tags and names from ISO 639.

Tags based on support in Windows 8.1's 'Myanmar Text' font.

Previously we were only setting this in hb_buffer_clear_contents(),
but set_length(0) is a valid way to reinitialize buffer to use with
new text.

Fixes last of scratch alignment warnings in hb-coretext.

Patch from Scott Fleischman.  Warnings were:

harfbuzz/src/hb-font-private.hh:121:42: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-font-private.hh:126:42: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-font-private.hh:400:85: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-ot-layout-common-private.hh:1115:37: Implicit conversion
loses integer precision: 'long long' to 'int'
harfbuzz/src/hb-ft.cc:421:97: Implicit conversion loses integer
precision: 'unsigned long long' to 'int'
harfbuzz/src/hb-ft.cc:422:97: Implicit conversion loses integer
precision: 'unsigned long long' to 'int'

Patch from Jonathan Kew.

Patch from Emil Eklund.

See thread started by Jonathan with subject "an optimization for complex
fonts".

This reverts commit d5bd0590.

The reasoning behind that logic was flawed and made under
a misunderstanding of the original problem, and caused
regressions as reported by Jonathan Kew in thread titled
"tibetan marks" in Oct 2013.  Apparently I have had fixed
the original problem with this commit:

  7e08f125

So, revert the faulty commit and everything seems to be in good
shape.