Safe overload of `FwpmEngineOpen0` projects handle as `SafeFileHandle` despite no relation to file APIs

[DoctorKrolic]

Actual behavior

The last parameter of native overload of FwpmEngineOpen0 is HANLE*. In the friendly overload it turns into out SafeFileHandle. Why file handle? This API has nothing to do with files and file-specific IsAsync API of that handle type throws cause the underlying handle is not a file handle in the first place.

Expected behavior

It doesn't seem like there is an existing non-abstract handle type that CsWin32 can use. Thus I believe it should emit its own SafeHANDLE class

Repro steps

1. NativeMethods.txt content:

FwpmEngineOpen0

Context

• CsWin32 version: 0.3.257
• Win32Metadata version (if explicitly set by project): N/A
• Target Framework: net10.0
• LangVersion (if explicitly set by project): N/A

[jevansaks]

In Win32metadata, HANDLE is defined with [RAIIFree(CloseHandle)] which means that all HANDLE types are closed via CloseHandle. In cswin32, that mapping to SafeFileHandle is here: https://github.com/microsoft/CsWin32/blob/9815c14196251f830d22959d695eacb9756a95f6/src/Microsoft.Windows.CsWin32/Generator.Invariants.cs#L59. I assume that's done because SafeFileHandle uses CloseHandle to close its handle and so it was convenient to re-use that type.

It looks like this particular out parameter, even though it's a HANDLE, should be treated as a domain-specific handle that must be closed via https://learn.microsoft.com/en-us/windows/win32/api/fwpmu/nf-fwpmu-fwpmengineclose0.

We need to fix this in win32metadata.