std: Second pass stabilization of sync

This pass performs a second pass of stabilization through the `std::sync`
module, avoiding modules/types that are being handled in other PRs (e.g.
mutexes, rwlocks, condvars, and channels).

The following items are now stable

* `sync::atomic`
* `sync::atomic::ATOMIC_BOOL_INIT` (was `INIT_ATOMIC_BOOL`)
* `sync::atomic::ATOMIC_INT_INIT` (was `INIT_ATOMIC_INT`)
* `sync::atomic::ATOMIC_UINT_INIT` (was `INIT_ATOMIC_UINT`)
* `sync::Once`
* `sync::ONCE_INIT`
* `sync::Once::call_once` (was `doit`)
  * C == `pthread_once(..)`
  * Boost == `call_once(..)`
  * Windows == `InitOnceExecuteOnce`
* `sync::Barrier`
* `sync::Barrier::new`
* `sync::Barrier::wait` (now returns a `bool`)
* `sync::Semaphore::new`
* `sync::Semaphore::acquire`
* `sync::Semaphore::release`

The following items remain unstable

* `sync::SemaphoreGuard`
* `sync::Semaphore::access` - it's unclear how this relates to the poisoning
                              story of mutexes.
* `sync::TaskPool` - the semantics of a failing task and whether a thread is
                     re-attached to a thread pool are somewhat unclear, and the
                     utility of this type in `sync` is question with respect to
                     the jobs of other primitives. This type will likely become
                     stable or move out of the standard library over time.
* `sync::Future` - futures as-is have yet to be deeply re-evaluated with the
                   recent core changes to Rust's synchronization story, and will
                   likely become stable in the future but are unstable until
                   that time comes.

[breaking-change]
I think I'm missing something but, why shouldn't `UnixStream` be `Send` and `Sync` ?