Add domain-specific handle types for WFP enumerations

[DoctorKrolic]

Follow up to #2185

Unfortunatelly, all handle close functions also accept an engine handle, so C# won't be able to generate SafeHandle wrappers for them, but at least this will stop C# from projecting them as SafeFileHandles, which is completely wrong

[jevansaks]

@DoctorKrolic did you try taking the locally-built Windows.Win32.winmd and using it with cswin32? What does it change about the cswin32 generated function signatures for the functions that use these types?

And then @riverar does the Rust projection support handle types with a CloseApi that has more than 1 parameter? And by "support" I mean "do a reasonable thing even though the projection probably can't auto-create them correctly".

[riverar]

Oh, I didn't see that these free functions had more than one arg. Right now, Rust will emit 0 as the second parameter in situations where there are multiple parameters.

[DoctorKrolic]

What does it change about the cswin32 generated function signatures for the functions that use these types?

Example previous friendly overload:

internal static unsafe uint FwpmConnectionCreateEnumHandle0(SafeHandle engineHandle, [Optional] winmdroot.NetworkManagement.WindowsFilteringPlatform.FWPM_CONNECTION_ENUM_TEMPLATE0? enumTemplate, out Microsoft.Win32.SafeHandles.SafeFileHandle enumHandle)

Friendly overload with changes from this PR:

internal static unsafe uint FwpmConnectionCreateEnumHandle0(SafeHandle engineHandle, [Optional] winmdroot.NetworkManagement.WindowsFilteringPlatform.FWPM_CONNECTION_ENUM_TEMPLATE0? enumTemplate, winmdroot.NetworkManagement.WindowsFilteringPlatform.FWPM_CONNECTION_ENUM_HANDLE* enumHandle)

Note, that the last parameter is no longer a SafeFileHandle, which is a good thing since SafeFileHandle will try to close handle with CloseHandle API upon disposal/destruction, which will lead to unexpected result. With new metadata CsWin32 didn't turn pointer into a managed ref for some reason, but this is an issue of CsWin32

[DoctorKrolic]

Right now, Rust will emit 0 as the second parameter in situations where there are multiple parameters.

This behavior is only valid when other parameter are optional or reserved. See microsoft/CsWin32#1603 as an example of the latter case

[riverar]

Regarding the 0:

Agree that isn't robust. I was just stating what Rust will do today. (This attribute is plagued with gotchas and problems that we've been talking about in other threads.)