System.Text.Json: Support for IAsyncEnumerable

[logiclrd]

This is my first pass at support for IAsyncEnumerable in System.Text.Json, which should satisfy issues #1569 and #1570 (except that, as commented in #1570, I don't think the deserialization can actually be asynchronous, because the object graph might have multiple IAsyncEnumerables in it, and each one would need its own pointer into the underlying stream).

This is my first time doing any work with C# 8, and also my first time doing any work with the .NET codebase, so I'm fully expecting there to be some things I overlooked, both in style and substance. :-)

My implementation builds upon IEnumerableDefaultConverter, which already has logic for reading a JSON array and passing the elements off to a collection that the subclass gets to define.

In addition to this, the converter needs to stash an IAsyncEnumerator between invocations. In the case of reference types, it can store this directly into WriteStackFrame using type covariance. For value types, type covariance isn't an option. So, two specializations of the IAsyncEnumerableOfTConverter are provided, customizing how the IAsyncEnumerator is stashed, using a simple wrapper for value types.

When deserializing into a field whose type is IAsyncEnumerable<T>, some class that implements the interface is needed, and I'm not aware of one built into the framework, so a simple AsyncEnumerableList that subclasses List<T> and adds an implementation of IAsyncEnumerable<T> (just synchronous pass-through, since the data is already there) is used.

I modeled the way converter objects get created after what I saw for IEnumerableOfT, with a factory that I register in sequence before the IEnumerableConverterFactory, on the assumption that if a class chooses to implement both, it probably would prefer that the async variant be used.

Finally, I added a handful of unit tests in new file IAsyncEnumerableTests.cs to capture the various wrinkles I could think of.

[layomia]

Thanks for the PR.

This feature needs to go through API review to verify if we want to take this approach, or something similar to the API suggestion in #1570 (comment). See the API review process here.

One thing that can move this forward is to consolidate your notes on #1570 into a single proposal, and compare the approach to #1570 (comment). Some code samples showing the API usage would be good as well.