lwsync() is a full read/write-barrier.  That's all we need, never
need sync().  I'm not sure why an isync() was used in fetch_and_add,
but since that's a read-modify-write, I just changed it to have
lwsync() on both sides.

Since add_int and cas are both read-modify-write, I wonder if we
also need a barrier after them.

Originally, glib's atomic_get was implemented as "memory_barrier; load".
I copied this into cairo, fontconfig, and harfbuzz.  However, that's
wrong.  Correct way is "load; memory_barrier".  The details are long
and hard to fully grasp.  Best to read:

  https://www.kernel.org/doc/Documentation/memory-barriers.txt

Also see my report against GNOME:

  https://gitlab.gnome.org/GNOME/glib/issues/1449

Note that this is irrelevant if C++11-like atomic ops are available.

To help TSan and be more "correct".

Although, all implementations just elevate that to ACQUIRE.
But requirement for us is just CONSUME.

This reverts commit b1e5650c.

After lots of head-scratching and finally finding the only truly
readable source to be the good old:

  https://www.kernel.org/doc/Documentation/memory-barriers.txt

I've convinced myself that we need consume memory-ordering on get().
The location of memory-barrier in a load should be after, not before
the load.  That needs fixing.  I'll do that separately.

We only use it before cmpexch, so relaxed is fine and faster for
common case.

Fixed the crasher in it.

This reverts commit 21fa170f.

Is crashing.  Oops.

Hopefully fixes bots.

Fixes https://github.com/harfbuzz/harfbuzz/issues/345

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.