Decide what WinRT classes to feature/include for next release

[timsneath]

We haven't shipped an updated version to pub.dev for a little while, because there's been lots of (good) churn on the WinRT front.

Before we ship again, we should decide which WinRT classes we publish/export. Right now, I've been adding classes purely based on whether they help us improve the projection, rather than whether they're useful to package consumers. We're still limited to classes that don't require async.

[ ] ApplicationData isn't necessary - that was requested when we were exploring a UWP runner for Flutter.
[X] Calendar and PhoneNumber are quite good examples, even if they're of somewhat useful utility
[X] Gamepad is mostly serviceable, although I need to test it with a real connected controller

What else would be useful to add for this initial wave?

[halildurmus]

I'm almost done adding support for asynchronous APIs (need to update the generator to project these APIs as Future and write some tests). It should be ready for review in a couple of days.). In fact, I plan to send a draft PR tonight, you might want to take a look.

Since Dart doesn't support async callbacks yet, I'm using Completer and polling IAsyncInfo's Status until the function completes (with sleeps in the meantime of course). After the async function completes, I call the GetResults method and use the result to complete the Future with Completer's complete() method. It seems to be working pretty well.

While working on the generator today, I realized that the work I'm going to do would also allow us to project Pointer<COMObject> types to their respective types. For example, ICalendar's Clone() would return Calendar instead of Pointer<COMObject>.

What else would be useful to add for this initial wave?

I don't have anything in my mind right now but after we land these changes, I think we will have a lot of options to choose from 😄.

[timsneath]

Things to do to ship a 3.0.0-pre (draft for discussion):

• Move WinRT exports to a separate library/libraries within this package (win32/winrt.dart?) just like winsock2 is exposed as a separate library
• Establish the nature of the breaking changes, particularly for COM, and write up a migration guide
• Validate and edit the list of WinRT shipped classes, per comment above
• Improve documentation and examples for WinRT
• Tidy up the README by moving the examples table elsewhere and doing a better job of establishing the value proposition of this package
• Make sure that analyzer lints are resolved in the configuration pana uses them