Reconsider null SafeHandle handling

[AArnott]

Now that I'm looking at that code some more, I'm also wondering why default(winmdroot.Foundation.HANDLE) is used when hMonitor is null, and why the call to DestroyPhysicalMonitor is still made. That would result in a 0 HANDLE, which is an actually valid handle you could get from PHYSICAL_MONITOR.

Originally posted by @User1785604260 in #753 (comment)

We should throw on null SafeHandle if the metadata does not include [Optional] for that parameter.
When it is optional, we should use a handle value that is documented as an invalid handle value the metadata rather than assume default(T) is suitable for a missing handle.

[AArnott]

Well, my fix for this may not address this particular feedback related to monitors, because DestroyPhysicalMonitor takes a HANDLE which is generally defined with both 0 and -1 being invalid handle values, so CsWin32 could theoretically emit either one when the SafeHandle is null.

[AArnott]

@User1785604260 I don't know why a 0 HANDLE would represent something valid, considering HANDLE is documented as using 0 and -1 to represent an invalid handle. I tried in #760 to prefer -1 over 0 where both were 'invalid' to avoid the monitor issue, but doing so led to #810 so I'm going to revert to preferring 0 when it is a documented invalid value.