Fix NullReferenceException for null optional non-blittable struct parameters

[jevansaks]

Summary

Fixes #1739.

Calling an extern with a null optional pointer-to-non-blittable-struct parameter threw a NullReferenceException instead of passing a null pointer. The canonical repro from the issue:

PInvoke.MiniDumpWriteDump(
    process.SafeHandle,
    (uint)Environment.ProcessId,
    dumpStream.SafeFileHandle,
    MINIDUMP_TYPE.MiniDumpWithThreadInfo,
    ExceptionParam: null,
    UserStreamParam: null,
    CallbackParam: null); // -> NullReferenceException

Root cause

MINIDUMP_CALLBACK_INFORMATION is non-blittable in the default AllowMarshaling mode because it contains a delegate field (MINIDUMP_CALLBACK_ROUTINE). A pointer to a managed type is illegal, so CsWin32 fell back to emitting the extern parameter with an in modifier. The friendly overload exposed it as T? and took the null path via ref Unsafe.NullRef<T>(). Because the struct is non-blittable, the P/Invoke marshaler must build a native copy and dereferences the null reference while marshaling it, throwing NullReferenceException.

This affects any optional [In] (not [Out]) parameter that points to a non-blittable struct, not just MiniDumpWriteDump. MiniDumpWriteDump was actually the motivating case for the original optional-pointer feature (#578), but its test only checked the friendly signature shape, never the runtime null behavior.

Fix

Emit such parameters as a T[] array instead of an in parameter — exactly what CsWin32 already does for non-blittable struct fields:

• A null array marshals to a null pointer.
• A single-element array marshals to a pointer to the struct.

The friendly overload continues to expose the parameter as a nullable T?, and now forwards param.HasValue ? new[] { param.Value } : null to the extern. The public friendly API is unchanged (still T?); only the internal extern signature changes from in T to T[] for these non-blittable cases.

Generated code before/after (friendly overload argument for CallbackParam):

// before (throws for null):
CallbackParam.HasValue ? &CallbackParamLocal : ref Unsafe.NullRef<...>()
// after:
CallbackParam.HasValue ? new[] { CallbackParam.Value } : null

Blittable optional struct pointers (e.g. ExceptionParam, UserStreamParam) are unaffected and keep the existing pointer projection.

Tests

• Added runtime tests in GenerationSandbox.Tests that actually call MiniDumpWriteDump:
  • NullOptionalPointerParametersDoNotThrow — the regression: CallbackParam: null now succeeds instead of throwing.
  • CallbackParameterIsMarshaled — passes a real callback and asserts it is invoked, exercising the single-element-array marshaling path.
• Existing GeneratorTests.MiniDumpWriteDump_AllOptionalPointerParametersAreOptional continues to pass (friendly params are still T?).

Validation

• Repro project returns 0x1 (success) with CallbackParam: null, no NRE.
• All 812 non-HighMemory generator tests pass.
• Everything_NoFriendlyOverloads and the FullMarshaling "Everything" generations pass (all APIs + friendly overloads still compile).

[jevansaks]

@Sergio0694 when you have a moment, could you please re-review? All CI is green now (GitHub Actions + the ADO pipeline).

Since the earlier reviews, the regression coverage changed based on CI feedback:

• The #1739 fix itself is unchanged.
• The runtime regression test now lives in ThreadpoolCallbackTests and actually executes interop on TrySubmitThreadpoolCallback, covering both the null path (null → null array → null pointer, the original NRE) and the non-null path (value → single-element array → pointer) by confirming the submitted native threadpool callback runs.
• Removed the earlier MiniDumpWriteDump runtime test: self-dumping the current process suspends all other threads while walking memory and could nondeterministically deadlock the test host (reproduced as ~4/8 net10 hangs locally and a hang dump in CI), even with no managed callback. The threadpool test exercises the same generated marshaling pattern safely (stress-verified 12/12 clean on net10).

Thanks!