In macOS 10.12, the `OSMemoryBarrier` and related APIs were deprecated
in favor of using `std::atomic`. On the way to supporting `std::atomic`,
we can favor using the "Intel primitives" which are also available on
macOS.

https://github.com/behdad/harfbuzz/issues/585

Patch from Volker Simonis.

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

Set requested windows header to Vista.  See discussion:

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

Many GCC versions don't define __arm64__

See thread "[HarfBuzz] compilation error of 0.9.26 with MinGW"
started by Werner.

This almost reverts 2761e8a6,
but only if under MINGW32, so it doesn't affect MSVC.

I added these because the older mingw32 toolchain didn't have
MemoryBarrier().  The newer mingw-w64 toolchain however has.
As reported by John Emmas this was causing build failure with
MSVC (on glib) because of inline issues.  But that reminded me
that we may be taking this path even if the system implements
MemoryBarrier as a function, which is a waste.  So, just remove
it.

Instead of checking for compiler, check for platform.

Based on fontconfig patch from Raimund Steger.

Patch from John Ralls.

Not sure how to handle iOS.

Now that we have pthread detection in configure, we don't need Glib
anymore.  Glib will only be a Unicode data provider.

Apparently the configure test is not enough...

Gonig to use these for lock-free linked-lists, to be used for
hb_language_t among other things.

We never use them in fact...

I'm just adjusting these as I better understand the requirements of
the code and the guarantees of each operation.

According to:
http://msdn.microsoft.com/en-us/library/65tt87y8.aspx

MemoryBarrier() is the right macro to protect these, not _ReadBarrier()
and/or _WriteBarrier().

As pointed out by Jonathan Kew.