Allow IAsync...WithProgress to report intermediate results

[oldnewthing]

Clients of IAsync...WithProgress are permitted to call GetResults() before the operation has completed, allowing them to observe partial results. This behavior is necessary because the Progress type must be a value type, but the operation may want to report reference types in their progress reports. The way to do that is to report the reference type as the GetResults().

The coroutine itself can use the set_result() method on the progress token to report a result prior to completion, and can set a new intermediate result as often as desired prior to the completion of the coroutine. The value passed to co_return acts as the final result of the coroutine. If set_result() is never called, then the intermediate result is an empty result (null for reference types, default-initialized for value types).

In practice, the result of the coroutine is usually a reference type, and the common pattern for coroutines that want to report a reference type as progress is to create the result object, pass it to set_result() at the start of the coroutine, update the result object as the coroutine progresses, and (redundantly) pass the same result object to co_return when the coroutine completes.

IAsyncOperationWithProgress<Muffin, double> BakeMuffinAsync()
{
    auto progress = co_await get_progress_token();

    Muffin muffin;
    Muffin.Diameter(5);
    progress.set_result(muffin);
    progress(0.0);

    muffin.Diameter(5.2);
    progress(0.5);

    muffin.Diameter(6);
    progress(1.0);

    co_return muffin;
}

Since clients of ...WithProgress are permitted to call GetResults() prior to completion, this introduces a few new wrinkles.

1. We need to use the lock to ensure a client doesn't try to read a partial result at the same time we are writing a new one.
2. The GetResults() method must return a copy of the result. This is true even if the coroutine has completed, because a progress handler might go off and do some asynchronous work, and then come back and ask for the intermediate result. If GetResults() on a completed coroutine consumes the result, then the async progress handler and the co_await will compete to retrieve the completed results, and somebody will lose.

As a result, ...WithProgress coroutines are slightly more expensive than non-progress coroutines due to the extra locking and copying. Fortunately, it's mostly pay-for-play. If a coroutine never calls set_result(), and the client never calls GetResults() from its progress handler, then there is no new lock contention. The final copy is unavoidable, but fortunately, the result is usually a reference type, so you just pay an extra AddRef/Release pair.

[kennykerr]

Looks good - thanks!