Handle COM disconnect errors when cancelling WinRT async operations (3.0)

[Sergio0694]

Summary

Prevent app crashes when an IAsyncInfo.Cancel() call from the cancellation callback in AsyncInfoTaskCompletionSource fails because the backing COM server has been disconnected.

Motivation

When awaiting a WinRT async API such as:

await SomeWinRTAPIAsync().AsTask(token);

if the underlying object lives in a COM server that has died, cancelling token would invoke IAsyncInfo.Cancel() from inside a CancellationToken callback. That call would then fail with RPC_E_DISCONNECTED (or related HRESULTs). The exception would propagate out of the cancellation callback and be re-thrown by CancellationTokenSource.Cancel() on whichever thread invoked it (often a thread pool thread), tearing down the entire process.

The pre-existing try/catch around the cancellation registration only protected the rare path where the token was already cancelled at registration time, since CancellationToken.Register(...) only invokes the callback synchronously in that case. In the typical flow, where cancellation happens later, nothing was guarding the Cancel() call.

Changes

• src/WinRT.Runtime2/InteropServices/AsyncInfo/TaskCompletionSources/AsyncInfoTaskCompletionSource{TProgress}.cs: collapsed the two cancellation registrations (one to mark the task cancelled, one to call IAsyncInfo.Cancel()) into a single OnCancellation callback. The callback first calls TrySetCanceled(_cancellationToken) to preserve the original ordering (so Canceled wins as the task state), then calls IAsyncInfo.Cancel() inside a try/catch that swallows any exception. This ensures no exception can escape the callback and crash the process.
• src/WinRT.Runtime2/InteropServices/AsyncInfo/TaskCompletionSources/AsyncInfoTaskCompletionSource{TResult, TProgress}.cs: same treatment for the generic TResult variant.