This changes the default load_flags of fonts created using
hb_ft_font_create() from NO_HINTING to DEFAULT.  Hope that doesn't
break too much client code.

Code calling hb_ft_font_set_funcs() is unaffected.

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

Based on data from http://upstream-tracker.org/versions/harfbuzz.html
Resolves #103

For discussion see:

  http://lists.freedesktop.org/archives/harfbuzz/2012-April/001905.html

Over time we have had added NO_HINTING all over the place in hb-ft.  Finish it off.
Not setting ppem on hb-font disables get_contour_point() calls which is good anyway.

See comments in the commit.

When I originally wrote hb-ft, FreeType objects did not support reference
counting.  As such, hb_ft_face_create() and hb_ft_font_create() had a
"destroy" callback and client was responsible for making sure FT_Face is
kept around as long as the hb-font/face are alive.

However, since this was not clearly documented, some clienets didn't
correctly did that.  In particular, some clients assumed that it's safe
to destroy FT_Face and then hb_face_t.  This, indeed, used to work, until
45fd9424, which make face destroy access
font tables.

Now, I fixed that issue in 395b3590 since
the access was not needed, but the problem remains that not all clients
handle this correctly.  See:

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

Fortunately, FT_Reference_Face() was added to FreeType in 2010, and so we
can use it now.  Originally I wanted to change hb_ft_face_create() and
hb_ft_font_create() to reference the face if destroy==NULL was passed in.
That would improve pretty much all clients, with little undesired effects.
Except that FreeType itself, when compiled with HarfBuzz support, calls
hb_ft_font_create() with destroy==NULL and saves the resulting hb-font on
the ft-face (why does it not free it immediately?).  Making hb-face
reference ft-face causes a cycling reference there.  At least, that's my
current understanding.

At any rate, a cleaner approach, even if it means all clients will need a
change, is to introduce brand new API.  Which this commit does.

Some comments added to hb-ft.h, hoping to make future clients make better
choices.

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

We require FreeType >= 2.8.3.  This symbol was introduced earlier
than that.

HB_MEMORY_MODE_READONLY_MAY_MAKE_WRITABLE is deprecated and fairly
useless now.

Apparently they are not (advertised as?) safe on BSD systems.
We ignore the case of static libraries.

Whitelisted on glibc, Android, and MSVC / mingw.

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

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'

Lohit-Punjabi has a upem of 769!  We were losing one unit in our
code, and FreeType is losing another one...  Test with U+0A06.
Has an advance of 854 in the font.  We were producing 852.
Now we do 853, which is what FreeType is telling us.

Based on patch from Jonathan Kew, as reported on the mailing list.

This changes the semantics of get_glyph() callback and expect that
callbacks return false if the requested variant is not available, and
then we will call them back with variation_selector=0 and will retain
the glyph for the selector in the glyph stream.

Apparently most Mongolian fonts implement the Mongolian Variation
Selectors using GSUB, not cmap.

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

Note that this doesn't fix the Mongolian shaping yet, because the way
that's implemented is that the, say, 'init' feature ligates the letter
and the variation-selector.  However, since currently the variation
selector doesn't have the 'init' mask on, it will not be matched...

That flag is redundant, deprecated, and ignored since April 2011.
From FreeType git log:

commit 8c82ec5b17d0cfc9b0876a2d848acc207a62a25a
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Thu Apr 21 08:21:37 2011 +0200

    Always ignore global advance.

    This makes FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH redundant,
    deprecated, and ignored.  The new behavior is what every major user
    of FreeType has been requesting.  Global advance is broken in many
    CJK fonts.  Just ignoring it by default makes most sense.

    * src/truetype/ttdriver.c (tt_get_advances),
    src/truetype/ttgload.c (TT_Get_HMetrics, TT_Get_VMetrics,
    tt_get_metrics, compute_glyph_metrics, TT_Load_Glyph),
    src/truetype/ttgload.h: Implement it.

    * docs/CHANGES: Updated.

The fallback happens in higher level already.  No need to do here.

Implemented for Arabic, Hebrew, and generic marks.
Activated if no GPOS table present.

The calculations were wrong.

FreeType makes it really hard to set size and ppem independently.
For now, disable it.  Need to come up with a fix later.

We're free!  Lazy or immediate...

Using graphite2's comparerenderer suggests that this makes hb-ft 15
times faster.  No caching layer needed anymore.

Remove hb_ft_get_font_funcs() as it cannot be used by the user anyway.

Add hb_ft_font_set_funcs().  Which will make the font internally use
FreeType.  That is, no need for the font to have created using the
hb-ft API.  Just create using hb_face_create()/hb_font_create() and
then call this on the font (after having set font scale).  This
internally creates an FT_Face and attached to the font.