Test for wakers being swapped about futures-concurrency

[eholk]

This is mostly a check to guard against error-prone runtime implementations. The actual right thing to do here would be to document that runtimes must associate a future with a waker after it's been passed once, so the complexity from this lives in the runtime - and we don't have to account for it in every future.

I'm not sure this is actually desirable. To me the main thing a waker does is moves a task from the blocked list to the ready queue. If you move a task between worker threads, each thread will have a different blocked and ready queue, so it makes sense that the waker would change.

I guess you could get around this by having some behind-the-scenes indirection in the waker. There's also the issue of updating stale wakers, so maybe it is a runtime correctness issue after all.