Add an InterlockedExchange64 () function for 64-bit atomic xchg.

This is currently implemented in terms of InterlockedCompareExchange64 ()
in order to work around various silly compiler bugs with the 64-bit
variant of __sync_val_compare_and_swap () on Apple targets.
Add FIXME note to atomic.h for platforms that lack some atomic functions.

This is unlikely to matter since these platforms are more or less
dead as far as Mono's back ends go.
Add InterlockedAdd () and InterlockedAdd64 () functions.
Add 64-bit variants of InterlockedIncrement () and InterlockedDecrement ().
Correct the semantics for mono_atomic_store_seq ().

It should issue full memory barriers before and after the
store to guarantee sequential consistency.
Add a mono_atomic_load_seq () function.

This is the load equivalent of mono_atomic_store_seq ().
Use real atomics for Interlocked.Increment ()/Decrement () in all cases.
Use InterlockedExchange64 () for Interlocked.Exchange () for double/long.

Avoids using a lock on 32-bit systems and makes the code saner.
Use InterlockedCompareExchange64 () for Interlocked.CompareExchange (double, ...).

Avoids using a lock on 32-bit systems and makes the code saner.
Use InterlockedAdd ()/InterlockedAdd64 () for the Interlocked.Add () overloads.
Use mono_atomic_load_seq () in Interlocked.Read ().

This *ensures* that we do the right thing everywhere and also
makes the code less ugly for the 32-bit / 64-bit cases.
Use mono_memory_barrier () for Thread.MemoryBarrier ().

This gets rid of the rather hacky lock-based barrier.
Move the unaligned 64-bit CAS hack to atomic.c.

Since we now rely on InterlockedCompareExchange64 () in quite a few
places that involve managed references, it's better to just put this
in one place.

Also added a HACK note so we don't forget about it.
Get rid of the mono_interlocked_mutex.

No code paths use it anymore.
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 atomic operations 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.
* 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
Fix an ifdef in atomic.c to match the define in atomic.h.