Remove unneeded NetBSD code path from atomic.h.
Simplify the ifdeffery in atomic.c/.h a bit.
Use host preprocessor identifiers in atomic.c, not target.

Here we care about the system we run on, not the kind of
system that Mono is built to compile for.
Remove unneeded ARM code from atomic.c.
Use GCC atomics on s390x.
Remove MONO_ARCH_SAVE_REGS from threading icalls.
Kill the Cygwin hack in mono-membar.h.

We only support GCC 4.x in Cygwin now.
Use mono_memory_barrier () for Thread.MemoryBarrier ().

This gets rid of the rather hacky lock-based barrier.
Add implementations of various interlocked functions to atomic.c/.h.

Mainly 64-bit variants, but also InterlockedAdd ().
Add interlocked read/write functions to atomic.c/.h.

These are guaranteed to have sequential consistency regardless
of the bitness of the machine they run on.
Move definition of NEED_64BIT_CMPXCHG_FALLBACK to top of atomic.c.
Use __sync_sub_and_fetch () for atomic decrements for clarity.
Use InterlockedRead64 () for Interlocked.Read (long&).
Use InterlockedIncrement64 () for Interlocked.Increment (long&).
Use InterlockedDecrement64 () for Interlocked.Decrement (long&).
Use InterlockedExchange64 () for Interlocked.Exchange (long&, long).
Use InterlockedExchange64 () for Interlocked.Exchange (double&, double).
Use InterlockedAdd () for Interlocked.Add (int&, int).
Use InterlockedAdd64 () for Interlocked.Add (long&, long).
Correct our implementation of Thread.VolatileRead ()/VolatileWrite ().

We have various issues:

* All of the functions assumed that doing volatile loads/stores was
  enough, when load-acquire, store-release semantics were actually
  needed. This may have worked before purely by chance. We now use
  proper memory barriers so that we don't have to hope for the
  compiler and CPU to do the right thing.
* Removes the hack for 64-bit quantities on 32-bit systems. This is
  no longer needed now that we use explicit memory barriers in
  these functions. Also, these functions are not supposed to do
  atomic reads/writes in the first place - they're purely about the
  memory barrier semantics.
* The VolatileWrite (object&, object) overload was not using the
  volatile qualifier at all, thus not getting volatile semantics
  as per: http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html