Fix resumability of iteration over IAsyncEnumerable<'T>

[abelbraaksma]

This is a continuation of #36. That PR merely added a bunch of tests and some small attempts at fixing this. These tests are deliberately failing as they showcase the issue at hand.

TODO:

• Fix allowing multiple calls to GetAsyncEnumerator() of the taskSeq CE and using it as an iterator
• When looping twice over an original taskSeq result must be equal, or, for side effects, show the side effects again
• Fix calling MoveNextAsync of the taskSeq CE after it returns false: it should continue to return false
• Fix calling Current before the first call to MoveNextAsync (the docs say its behavior is undefined, but similar to how IEnumerator<_> is implemented usually, just return Unchecked.defaultof).
• Similarly to the previous point, allow calling Current after completion of a finite sequence (i.e. when MoveNextAsync has returned false).
• Fix delayed (i.e., yielded) tasks. If result is not immediate, MoveNextAsync() called on a copied enumerator will return Faulted with an NRE

The above scenarios presently return an InvalidOperationException, as described in detail in issue #39.

[abelbraaksma]

Ok. So, here's what we're at now:

• The exceptions raised when calling MoveNextAsync() too often, or Current too early or after-the-end are gone, which is a big win
• Synchronous sequences appear to work just fine now. With synchronous I mean where there is no task yielding during processing, like taskSeq { yield 1; yield 2 }.
• Asynchronous sequences (like taskSeq { do! Task.Delay 200 }) fail now in mysterious ways. Where previously there were early exceptions, now it appears to sometimes end in a deadlock, even with a (nested) empty sequence. This is somewhat worrying.

To emphasize the last point, I duplicated all tests we had so far, and made a synchronous and asynchronous batch. It is clear that the state of the ValueTask<bool> is incorrectly yielded and/or read again when already yielded before, leading, in most cases, to an NRE inside the ValueTaskSourceCore, and in some cases to deadlocks or other behavior leading to XUnit crashing.

[abelbraaksma]

Thanks and credits to @dsyme for helping me out today, and explaining more of, the resumable state machine logic. See #49 of that initial work to get resumption back to zero. This removes the hack that I used here, through Unchecked.defaultof<_>, that only partially worked.

There's still some cleaning up to do and apply suggested optimizations to the GetAsyncEnumerator() bits, but I'll do that in a follow-up PR, i.e. #51.