Add a limited prim type lookup for safer const expr evaluation
remove a layer of indirection from most intrinsics
auto merge of #11917 : thestinger/rust/intrinsic, r=alexcrichton
auto merge of #11955 : alexcrichton/rust/fix-unwinding-on-mac-64, r=cmr

I believe that this is leading to lots of failures on the bots.

cc #11954
auto merge of #11832 : jfager/rust/r5900, r=alexcrichton

I tried a couple of different ways to squash this, and still don't think this is ideal, but I wanted to get it out for feedback.

Closes #5900
Closes #9942

There are a few scenarios where the compiler tries to evaluate CastExprs without the corresponding types being available yet in the type context:  https://github.com/mozilla/rust/issues/10618, https://github.com/mozilla/rust/issues/5900, https://github.com/mozilla/rust/issues/9942

This PR takes the approach of having eval_const_expr_partial's CastExpr arm fall back to a limited ast_ty_to_ty call that only checks for (a subset of) valid const types, when the direct type lookup fails.  It's kind of hacky, so I understand if you don't want to take this as is.  I'd need a little mentoring to get this into better shape, as figuring out the proper fix has been a little daunting. I'm also happy if someone else wants to pick this up and run with it.

This closes 5900 and 9942, but only moves the goalposts a little on 10618, which now falls over in a later phase of the compiler.
Shuffle around ownership in concurrent queues

Beforehand, using a concurrent queue always mandated that the "shared state" be
stored internally to the queues in order to provide a safe interface. This isn't
quite as flexible as one would want in some circumstances, so instead this
commit moves the queues to not containing the shared state.

The queues no longer have a "default useful safe" interface, but rather a
"default safe" interface (minus the useful part). The queues have to be shared
manually through an Arc or some other means. This allows them to be a little
more flexible at the cost of a usability hindrance.

I plan on using this new flexibility to upgrade a channel to a shared channel
seamlessly.
Rewrite channels yet again for upgradeability

This, the Nth rewrite of channels, is not a rewrite of the core logic behind
channels, but rather their API usage. In the past, we had the distinction
between oneshot, stream, and shared channels, but the most recent rewrite
dropped oneshots in favor of streams and shared channels.

This distinction of stream vs shared has shown that it's not quite what we'd
like either, and this moves the `std::comm` module in the direction of "one
channel to rule them all". There now remains only one Chan and one Port.

This new channel is actually a hybrid oneshot/stream/shared channel under the
hood in order to optimize for the use cases in question. Additionally, this also
reduces the cognitive burden of having to choose between a Chan or a SharedChan
in an API.

My simple benchmarks show no reduction in efficiency over the existing channels
today, and a 3x improvement in the oneshot case. I sadly don't have a
pre-last-rewrite compiler to test out the old old oneshots, but I would imagine
that the performance is comparable, but slightly slower (due to atomic reference
counting).

This commit also brings the bonus bugfix to channels that the pending queue of
messages are all dropped when a Port disappears rather then when both the Port
and the Chan disappear.
Re-implement select() for channels

The major things to overcome in this implementation were to prevent spurious
wakeups during upgrading, and be sure to go to sleep on the proper port during
selection (taking into account pending upgrades).

The interface to Select has been tweaked, and it's about as bad as it was
before, and just as slow as it was before.

This does re-implement some portions of channels, but they're mostly just small
portions that are trivial rewrites.
Bring back try_send_deferred and prevent overflow
Test fixes and rebase conflicts