Prevent waitable-set.{wait,poll} from being used at the same time as sync built-ins

[lukewagner]

This PR is one way to resolve the ambiguity discovered in #642.

One option is to give the sync operations "priority" over the waitable-set, and that's what I started with. But it's a pretty complex behavior to test for and so it seems likely to be a bug in production. It's also not clear if it's actually the desired behavior or whether it might be masking a bug that a trap would've helped catch much earlier.

So instead, this PR just traps, both if attempting to start a sync operation on a waitable that's already in a waitable-set or, conversely, if trying to add a waitable to a waitable-set when there's already a sync operation in progress. This is also a conservative choice, and we could switch to the above later if a compelling reason arose.

[alexcrichton]

To me this seems reasonable yeah in the sense that in higher-level situations when you're performing a future/stream operation you've probably already got ownership of the future/stream so you should be able to have complete control over the state of the stream before/after so having extra requirement shouldn't be too onerous.