Applying unary minus operator to unsigned int causes the following
warning on MSVS:

  warning C4146: unary minus operator applied to unsigned type, result still unsigned

Based on patch from Koji Ishi.

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

Using latest gobject-introspection, I don't seem to be having this
problem anymore:

  https://bugzilla.gnome.org/show_bug.cgi?id=707656

Removing that kludge makes language_t behave more like the way I expect it
in Python.

Also fixes:
https://github.com/behdad/harfbuzz/issues/91

Fixes user_data_t

Apparently the code is already standardized:
https://www.microsoft.com/typography/otspec/languagetags.htm

Very anaemic, needs to descripe the format understood by
hb_feature_from_string() etc., but it is just start.

The code is not standardized yet, but is used in some Google fonts.

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

This reverts commit 89cbd4d9.

See discussion:
https://bugzilla.gnome.org/show_bug.cgi?id=747772

Not sure we have any right now; motivated by this:
https://bugzilla.gnome.org/show_bug.cgi?id=747772

Annotate the output parameter.

It should not be freed by the caller.

Based on patch from Björn Breitmeyer

Previously, when creating an object from inert inputs (eg:
"hb_font_create(hb_face_get_empty())") we returned the inert
empty object.  This is not helpful as there are legitimate
usecases to do that.

We now never return the inert object unless allocation failed.

Tests are revised to reflect.

Part of https://github.com/behdad/harfbuzz/pull/68

Hopefully this results in fewer badly built HarfBuzz integrations.

s/atomic_int/atomic_int_impl/ and s/atomic_ptr/atomic_ptr_impl/
to bring it in par with hb_mutex_impl_t, then re-introduce
hb_atomic_int_t as a wrapper around hb_atomic_int_impl_t.

In hb_reference_count_t, make it clear the non-atomic get and set
are intentional due to nature of the cases they are used in
(comparison to -1 and the debug output/tracing).

Motivated by
https://github.com/behdad/harfbuzz/pull/92

out\debug\hb-buffer-deserialize-text.rl(47) : warning C6001: Using
uninitialized memory 'pos'.

Without the element-type they will be getting garbage, at least with
Python.

Fixes coretext notdef loop consisting of all default_ignorable glyphs

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

In hb-coretext, when we were using scratch buffer for book-keeping,
a reverse_range() caused by the notdef-insertion loop could mess up
our log_clusters.  Ouch!