Add an AtomicU64 type to std::sync::atomics

This also generalizes all atomic intrinsics over T so we'll be able to add u8
atomics if we really feel the need to (do we really want to?)
Enable the +v7 feature on Android by default

With the recently added double word CAS functionality on 32-bit ARM (enabled via
a 64-bit atomic instruction in LLVM IR), without some extra features enabled
LLVM lowers code to function calls which emulate atomic instructions. With the
v7 feature enabled, proper 64-bit CAS instructions are used on 32-bit arm.

I've been told that v7 for arm is what we should have been doing anyway. This is
overridable by providing some other non-empty feature string.
extra: Make room for more sync primitives
extra: Add an intrusive MPSC to be used soon
std: Hardcode pthread constants and structures

This allows for easier static initialization of a pthread mutex, although the
windows mutexes still sadly suffer.

Note that this commit removes the clone() method from a mutex because it no
longer makes sense for pthreads mutexes. This also removes the Once type for
now, but it'll get added back shortly.
extra: Re-add the Once primitve to extra::sync

This originally lived in std::unstable::mutex, but now it has a new home (and a
more proper one).
std: Remove try_send_deferred plus all fallout

Now that extra::sync primitives are built on a proper mutex instead of a
pthreads one, there's no longer any use for this function.
extra: Introduce a mutex type for native/green threads
Various bug fixes and rebase conflicts
auto merge of #11866 : alexcrichton/rust/atomic-u64, r=brson

Let's try this again.

This is an implementation of mutexes which I believe is free from undefined behavior of OS mutexes (the pitfall of the previous implementation).

This implementation is not ideal. There's a yield-loop spot, and it's not particularly fair with respect to lockers who steal without going through the normal code paths. That being said, I believe that this is a correct implementation which is a stepping stone to move from.

I haven't done rigorous benchmarking of this mutex, but preliminary results show that it's about 25% slower in the uncontended case on linux (same runtime on OSX), and it's actually faster than a pthreads mutex on high contention (again, not rigorous benchmarking, I just saw these numbers come up).