Add GC.AllocateUninitializedArray<T> polyfill

[paulomorgado]

Summary

Add source-compatible polyfill for GC.AllocateUninitializedArray(int, bool) which was introduced in .NET 5.0.

On older runtimes the implementation delegates to
ew T[length] (zero-initialized) for source compliance — code that calls this API compiles and runs correctly on all targets, though without the performance benefit of skipping zero-initialization.

Guard

#if !NET5_0_OR_GREATER — the native API exists from .NET 5.0 onward.

Changes

• src/Polyfill/GCPolyfill.cs — Canonical polyfill implementation
• src/Tests/GCPolyfillTests.cs — TUnit tests
• src/Consume/Consume.cs — Compile-time consume coverage
• api_list.include.md — Updated API list
• src/Split/{tfm}/GCPolyfill.cs — Per-TFM split copies

[SimonCropp]

I think pinned: true is problematic. It can't actually be polyfilled — the Pinned Object Heap is a runtime feature that landed in .NET 5, it's a region of the native GC heap, not some managed API hiding behind a private modifier.

silently ignoring it is pretty dangerous. The whole reason people pass pinned: true is to stash a pointer into the buffer and hand it off to native code for later (async I/O, native callbacks, long-running workers). On net5+ that's fine because POH arrays never move. With this polyfill the GC is free to relocate the array on the next compaction and the stored pointer is now aimed at whatever happens to live at that address — heap corruption that usually crashes far away from the actual bug, sometimes hours later. Not fun to debug.

Pure managed code and single-call P/Invoke are fine, but those aren't why anyone passes pinned: true in the first place.

I think drop the two-arg overload and just polyfill AllocateUninitializedArray(int length)

[paulomorgado]

Because I use it to allocate already pinned but always pin anyway, I never thought some could rely on that.

Maybe we should keep the parameter and throw on true.

[SimonCropp]

@paulomorgado yep, happy with that