Improve accuracy of supported OS versions for APIs

[sotteson1]

In order to improve on the supported OS platforms, and to avoid having to scrape the docs (which don't always seem to be accurate), we could build the .winmd multiple times with _WIN32_WINNT set to different versions. By looking at the differences, we could see which APIs are supported in which versions. This would not be part of every build. It would be a step we would run manually in order build up the platform versions input .rsp.

[mikebattista]

I've tried building with NTDDI_VERSION set to different values and that's full of issues.

I have an internal thread looking into better ways to source this information.

[riverar]

We might be better off just ignoring/dropping the attribute for now, get the APIs emitted, then move to a maintain-the-scraper-output stage where we can do an OS verison annotation pass. (I'm not sure anyone is using the attribute today.)

[tim-weis]

@riverar The SupportedOSPlatform attribute shows up in the generated CsWin32 bindings, and is subject to CA1416 diagnostics. When using the IFolderView interface, for example, you might get something like this:

warning CA1416: This call site is reachable on all platforms. 'IFolderView' is only supported on: 'windows' 5.1.2600 and later.

With CsWin32 still in beta, breaking changes would still be permissible, but there are clients that do use the attribute (even if not directly).

[riverar]

The values are wildly wrong so I hope no one is truly using them!

[timsneath]

Should we remove this principle from https://github.com/microsoft/win32metadata/blob/main/docs/projections.md, since these are unreliable?

`Language projections should support filtering available APIs based on the SDK version that a project targets