Before we were not accounting for possible differences in x_scale and
y_scale, as well as the signs of those.  All should be in good shape
now.

Also makes hb-view to use 8 bits of subpixel precision and shape at
requested size, instead of always shaping at upem and scaling results.

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.

Change New Tai Lue shaping engine from SEA to default

This is to reflect the UTC decision to change the encoding model of
New Tai Lue from logical to visual to be similar to Thai, Lao, and
Tai Viet: http://www.unicode.org/L2/L2014/14250.htm#141-C26

The visual encoding is already the current practice of encoding New
Tai Lue on the web anyway:
http://www.unicode.org/L2/L2014/14195-newtailue.txt

Fixes behdad/harfbuzz#66.

hb_blob_create() is considered C-only API.

Minimal shaping works now!

ICU exports them using LOCAL_EXPORT_C_INCLUDE_DIRS.

https://android-review.googlesource.com/#/c/121311/

Add #ifdef HB_USE_ATEXIT to fix -Wunused-function warnings

Fix hb_atomic_ptr_cmpexch -Wunused-value warnings

Fixes https://github.com/behdad/harfbuzz/pull/74

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.

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

Based on discussion someone else who had a similar issue, most probably
the user is releasing FT_Face before destructing hb_face_t / hb_font_t.
While that's a client bug, and while we can (and should) use FreeType
refcounting to help avoid that, it happens that we were accessing
the table when we didn't really have to.  Avoid that.

Fail if blob start plus length overflows; or if blob length
is greater than 2GB.  It takes a while for fonts to get to that
size.  In the mean time, it protects against bugs like this:

  http://www.icu-project.org/trac/ticket/11450

Also avoids some weird issues with 32bit vs 64bit systems
as we accept length as unsigned int.  As such, a length of
-1 will cause overflow on 32bit machines, but happily
accepted on a 64bit machine.  Avoid that.

This will crash now, if blob was created with wrong length.
Check for that coming next commit.