`--specific-deps` on *non-COM* bindings still has some `windows_core` references

[MarijnS95]

Summary

The expected output from windows-bindgen for non-COM bindings is to have no dependency on windows-core, since all building blocks can come from windows-result, windows-strings and windows-link. It seems a few slipped through though (and I expected this as it's an ongoing effort, just reporting this here to slowly get there eventually).

For this report I'm using oblique/named-lock#14 as a reference, where I tried this. The violators:

• windows_core::Error -> could simply be windows_result::Error;
• impl windows_core::Free for HANDLE -> unsure if this should be omitted or moved?
• windows_core::Param requirement for strings (to be able to pass a HSTRING into a Param<PCWSTR>?) -> also unsure where that should go.

Crate manifest

[target.'cfg(windows)'.dependencies]
# Must use windows-bindgen 0.64+ for --specific-deps. The generated
# bindings in turn require windows-result 0.4, which in turn only
# pairs with windows-core 0.62 (all the latest).
windows-link = "0.1"
windows-strings = "0.5" # Must match windows-core
windows-result = "0.4.0" # Must match windows-core
windows-core = "0.62" # TODO: Needs to be removed

Crate code

bindings.txt:

--out src/windows_bindings.rs

--specific-deps

--filter
    Windows.Win32.Foundation.CloseHandle
    Windows.Win32.Foundation.WAIT_ABANDONED
    Windows.Win32.Foundation.WAIT_OBJECT_0
    Windows.Win32.Foundation.WAIT_TIMEOUT
    Windows.Win32.System.Threading.CreateMutexW
    Windows.Win32.System.Threading.ReleaseMutex
    Windows.Win32.System.Threading.WaitForSingleObject
    Windows.Win32.System.Threading.INFINITE

[kennykerr]

Yes, this is a known limitation at this point. The windows-core crate needs to be further refactored to isolate COM support before this level of dependency isolation can be achieved.