Implement windows support using windows-bindgen

[Kijewski]

Looks like windows 0.47 already dropped: can we get a bump and release to that?

@Jake-Shadle this is also a prime candidate for windows-bindgen except for the use of COM objects, for which we're waiting on @kennykerr to separate manual code out into windows-core first; and then hope that crate releases less often if breaking changes are only in the metadata and generated output.

I recently tried this now that windows-bindgen is capable of generating "minimal" bindings that leverage windows-core 0.51 rather than the full windows crate.

Unfortunately/obviously this doesn't suffice the MSRV 1.48 policy of this crate thanks to edition = "2021" in the windows-core crate.

Diff is here: https://github.com/MarijnS95/iana-time-zone/compare/windows-core

I generated the bindings without --config package because this crate really shouldn't have Windows features leaking into its [features] array (beyond those being > appended at the end of Cargo.toml). Unfortunately this means the whole Windows.Globalization.Calendar type is generated including function signatures that depend on other types/modules, without cfg guards. All these extra types (and all their dependencies, etc) have to be included to make the Windows module compile; while users may end up not having to download the windows crate as a result, they may end up compiling more code that way.

Still appears to be a half-second (approx!) win though, running:

cargo clean && cargo b --timing

Before:

After:

CC @kennykerr, you might be interested in this. Note also that the compiler suggested that Windows.Foundation.DateTime and Windows.Foundation.TimeSpan could have been imported from windows_core::imp::*, should/could bindgen take care of that?

Originally posted by @MarijnS95 in #97 (comment)