CsWin32 can generate better friendly overload when optional native arrays are involved

[DoctorKrolic]

Currently generating RegEnumValue will produce the following friendly signatures:

WIN32_ERROR RegEnumValue(SafeHandle hKey, uint dwIndex, [Optional] Span<char>lpValueName, ref uint lpcchValueName, out uint lpType, [Optional] Span<byte> lpData, ref uint lpcbData)
WIN32_ERROR RegEnumValue(SafeHandle hKey, uint dwIndex, [Optional] Span<char>lpValueName, ref uint lpcchValueName, [Optional] Span<byte> lpData)

Let's focus on last 2 parameters: lpData and lpcbData. lpData is a pointer to a byte array and lpcbData is count of these bytes. This is correctly annotated in metadata via [MemorySize(BytesParamIndex = 7)] attribute. The point here is that both lpData and lpcbData are [Optional]. Since lpcbData is [In], it means it must be assigned a number of bytes in lpData on input. Therefore if this value is not provided (aka passed as null), lpData cannot be anything then also a null. Since lpcbData is upgraded to managed reference in friendly overload, CsWin32 generates 2 different overloads, in one of which it is precent, but in the other it is not. However, lpData is still provided in the second overload with omitted lpcbData, even though the only valid value for it in such circumstances is null. Given that matadata provides all necessary annotations, CsWin32 can be smart here and exclude lpData from the second overload as well and pass a null under the hood. Note, that in the "full" version of friendly overload lpData is still needed to be tagged with [Optional] since lpcbData is also [Out], thus it gets an actual expected number of bytes if lpData is null. If lpcbData was only [In], then that [Optional] annotation on lpData could be dropped as well