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

Bug 76494 - #!/usr/bin/python in testsuite

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

Make hb_test_tools.py compatible with python 3

On ArchLinux, /usr/bin/python is linked to python 3 so
HarfBuzz `make check` is broken there.

This makes hb_test_tools.py compatible with python 3 while
no breaking it on python 2.

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

[bindings] Fix *_from_string functions

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

I misunderstood how which works.

Of course, we don't really run it, autoreconf does.  We just
err if neither is available.  glibtoolize is the name it is
shipped under on OS X.  Reported by Adam.

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!

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

Before, the IntType::cmp functions providing this and was truncating
the hb_codepoint_t to 16bits before comparison.  I have no idea how
this was never discovered, and I'm too lazy to try to reproduce this
with Pango (which uses non-16bit codepoint numbers for missing glyphs).

I was hoping to see a nice speedup, but it resulted in a very minor one.