Add alternate implementations of synchronization primitives

[notgull]

This PR adds two alternate implementations of synchronization primitives:

• One based on loom. This can be enabled using cfg(loom). Unfortunately there is no real way to test this, since loom tests require some kind of synchronization primitive to make progress.
• One based on portable-atomic, enabled using the portable-atomic feature. This allows concurrent-queue to be used on platforms without available atomics.

Obsoletes #5

[taiki-e]

Thanks! Could you add tests for cfg(loom)? When we did something similar before in crossbeam, unbounded queue panicked with odd errors like tokio-rs/loom#283.

[notgull]

I added a basic spsc test for Loom, but I keep bumping my head on this panic:

thread 'spsc' panicked at 'Model exceeded maximum number of branches. This is often caused by an algorithm requiring the processor to make progress, e.g. spin locks.', /home/jtnunley/.cargo/registry/src/github.zerozr99.workers.dev-1ecc6299db9ec823/loom-0.5.6/src/rt/path.rs:136:9

I'm not that familiar with loom, but is there a way around this? If I have the receiver thread wait on a Condvar, it complains about the thread being deadlocked and panics.

[notgull]

With some tinkering, I built a channel implementation with loom primitives based on concurrent_queue, specifically to use in this test. It looks like it works well enough to be tested.

[taiki-e]

Thanks!

• Could you add docs about portable-atomic feature? like atomic-waker's docs
• I want to treat loom as an unstable cfg so docs in lib.rs is probably not needed, but could you document that it is unstable in Cargo.toml? like crossbeam-utils's Cargo.toml

[notgull]

Thank you for taking the time to review, @taiki-e! I implemented the suggestions you made.

The only real issue here is that running the CI now takes significantly longer. Even with LOOM_MAX_PREEMPTIONS=2, it looks like it still takes a few minutes to run. It's not really that big of a deal, and we could probably even get away with using LOOM_MAX_PREEMPTIONS=3 if we really wanted to.