Some clang versions define static_assert as a macro apparently, so we cannot
redefine it...

This reverts commit 94bfea0c.
This reverts commit 4e626278.

So we don't accidentally break it again.

John Emmas reported on mailing list that build with MSVC is failing.
Not sure why bots don't catch it, but this should fix.

Sorry for the noise, downstream custom builders.  Please adjust.

Found and fixed a couple bugs.

Found a couple multithreading issues.  Marked them with "XXX-MT-bug".

Removes volatile from fallback implementation.  That was handwavy
anyway.

If ever int is not 32bit, we'll fix this...

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).