Reconsider taking SafeHandle-derived types as input parameters

No semantically correct SafeHandle type is provided by CsWin32 when using GetCursorInfo with GetIconInfo and DrawIconEx, now that all handle parameters are SafeHandle:

var cursorInfo = new CURSORINFO { cbSize = Marshal.SizeOf(typeof(CURSORINFO)) };

if (!PInvoke.GetCursorInfo(ref cursorInfo))
    throw new Win32Exception();

//                           ↓ Options: abuse an existing SafeHandle type or declare one myself
if (!PInvoke.GetIconInfo(new WhatDoIWriteHere(cursorInfo.hCursor, ownsHandle: false), out var iconInfo))
    throw new Win32Exception();
    
// Calling DrawIconEx has the same issue.

Prior to everything becoming abstract SafeHandle, the following code worked. It's not as ergonomic as passing HCURSOR, but it is nicer than the two new options:

if (!PInvoke.GetIconInfo(new(cursorInfo.hCursor, ownsHandle: false), out var iconInfo))
    throw new Win32Exception();

I'm also not a fan of throwing away the parameter type information in this way. GetObject has parameter SafeHandle h now, for instance. A parameter like that doesn't instantly tell you what kinds of handle you can pass or how to obtain them.

Start by reviewing the generated signatures and call sites for GetCursorInfo, GetIconInfo, DrawIconEx, and GetObject, focusing on how SafeHandle parameters are represented. Done requires an agreed parameter-typing design that preserves applicable handle information without making the shown calls semantically incorrect.