Set requested windows header to Vista.  See discussion:

https://github.com/behdad/harfbuzz/commit/fbb2847f541389f40718af71c4945024ae177ab2#commitcomment-7054700

From
https://code.google.com/p/chromium/issues/detail?id=393896

Ouch!

Follows the order of the Arabic/Syriac specs.  Also don't stop
between rlig and calt in non-Arabic scripts.

Micro-tests for Arabic and Mongolian added for the latter.

This reverts bf029281 and fixes it properly.  That commit
was not enough as it was only inheriting the shaping_action
for prev_action, but not curr_action.

Micro-test added.

https://code.google.com/p/chromium/issues/detail?id=393896

We now handle U+FFFD replacement in hb_buffer_add_utf*().  Any other
manipulation can happen in user callbacks.  No need for this.

https://github.com/behdad/harfbuzz/commit/efe74214bbb68eaa3d7621e73869b5d58210107e#commitcomment-7039404

This reverts commit efe74214.

Conflicts:
	src/hb-ot-shape-normalize.cc

With this change, we now by default replace broken UTF-8/16/32 bits
with U+FFFD.  This can be changed by calling new API on the buffer.
Previously the replacement value used to be (hb_codepoint_t)-1.

Note that hb_buffer_clear_contents() does NOT reset the replacement
character.

See discussion here:

https://github.com/behdad/harfbuzz/commit/6f13b6d62daae4989e3cc2fe4b168e5c59650964

New API:

  hb_buffer_set_replacement_codepoint()
  hb_buffer_get_replacement_codepoint()

Like hb_buffer_add_utf32, but doesn't do any Unicode validation.
This is like what hb_buffer_add_utf32 used to be until a couple
commits ago.

Same as what we do for UTF-8 and UTF-16.

Originally we fixed those in 79d1007a.
However, fonts like MongolianWhite don't have GDEF, but have IgnoreMarks
in their LigatureSubstitute init/etc features.  We were synthesizing a
GDEF class of mark for Mongolian Variation Selectors and as such the
ligature lookups where not matching.  Uniscribe doesn't do that.

I tried with more sophisticated fixes, like, if there is no GDEF and
a lookup-flag mismatch happens, instead of rejecting a match, try
skipping that glyph.  That surely produces some interesting behavior,
but since we don't want to support fonts missing GDEF more than we have
to, I went for this simpler fix which is to always mark
default-ignorables as base when synthesizing GDEF.

Micro-test added.

Fixes rest of https://bugs.freedesktop.org/show_bug.cgi?id=65258

Enable tests that were disabled before, and adjust one test,
and add more tests.

Though, looks like gcc was smart enough to produce the same code
before...

Simplifies hb_in_range() calls as the type can be inferred.
The rest is obsessiveness, I admit.

It's both faster and produces smaller code.  Now I feel stupid for
not writing it this way before.

Only if the font doesn't support it.  Ie, this gives the user to
use non-Unicode codepoints as private values and return a meaningful
glyph for them.  But if it's invalid and font callback doesn't
like it, and if font has U+FFFD, show that instead.

Font functions that do not want this automatic replacement to
happen should return true from get_glyph() if unicode > 0x10FFFF.

Replaces https://github.com/behdad/harfbuzz/pull/27

Test passes now.

Currenty fails.  Ouch!