LibraryImportGenerator: prep for unsafe-v2

[EgorBo]

Prep for unsafe-v2 where unsafe on types is illegal and unsafe on methods no longer opens an unsafe context in the body. Emit code valid under both old and new rules:

• Don't add unsafe to the generated stub's containing type (user's own modifiers are still copied as-is).
• Wrap wrapper-stub bodies in an unsafe { } block instead.
• Forwarder stubs (bodyless extern) are unchanged.

The exact behavior of LIG in unsafe-v2 context is currently blocked by dotnet/roslyn#84555 decision.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the LibraryImportGenerator (and downlevel variant) to stop emitting unsafe on containing type declarations and instead emit an explicit unsafe { ... } block inside wrapper stub bodies, keeping the generated code shape compatible with evolving C# unsafe semantics. It also adds/adjusts unit tests to lock in the new emitted structure and updates an existing diagnostic expectation accordingly.

Changes:

• Wrap generated wrapper stub bodies in a single unsafe { } statement block (instead of relying on unsafe on the containing type).
• Update ContainingSyntaxContext to wrap members in containing syntax without injecting an unsafe type modifier; rename the helper accordingly.
• Add UnsafeCodeGeneration structural tests and update CompileFails.ValidateRequireAllowUnsafeBlocksDiagnostic expectations.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/libraries/System.Runtime.InteropServices/tests/LibraryImportGenerator.UnitTests/UnsafeCodeGeneration.cs	Adds structural unit tests verifying wrapper stubs use a body unsafe block and that the generator does not inject unsafe onto containing types (while preserving user-authored unsafe).
src/libraries/System.Runtime.InteropServices/tests/LibraryImportGenerator.UnitTests/CompileFails.cs	Updates expectations/comments for AllowUnsafeBlocks=false now that trivial forwarder stubs don’t trigger CS0227 via generated type-level unsafe.
src/libraries/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/ContainingSyntaxContext.cs	Renames/remodels member wrapping to avoid adding unsafe to containing types when emitting syntax-wrapped members.
src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs	Wraps wrapper stub bodies in unsafe { } and switches to the new containing-syntax wrapper API.
src/libraries/System.Runtime.InteropServices/gen/DownlevelLibraryImportGenerator/DownlevelLibraryImportGenerator.cs	Mirrors the wrapper-stub unsafe { } body emission and containing-syntax wrapper API change for downlevel generation.

[EgorBo]

PTAL @AaronRobinsonMSFT (assuming @jkoritzinsky is OOO)

[jtschuster]

Could we also add test cases for forwarding stubs and marshalling stubs with 'unsafe' on the method declaration?

public static unsafe partial void Method();

public static unsafe partial void Method2(string s, int* i);

[jtschuster]

nit: I don't think we should have a comment referencing warnings that aren't present anymore.

Suggested change

	// The generator no longer emits an 'unsafe' modifier on the containing type, and the trivial
	// (forwarder) stubs it produces here contain no unsafe code, so no CS0227 is reported. The
	// analyzer still reports SYSLIB1062 once per compilation to recommend enabling AllowUnsafeBlocks.
	// The analyzer reports SYSLIB1062 once per compilation to recommend enabling AllowUnsafeBlocks.

[jtschuster]

nit: I don't think the doc comment needs to explain how this differs from the old behavior.

Suggested change

	/// Unlike the containing-type modifiers that are copied verbatim from the user's declaration,
	/// this intentionally does not add an <c>unsafe</c> modifier to any containing type: generated
	/// members that require an unsafe context open an explicit <c>unsafe</c> block in their body instead.
	/// This keeps the output valid under both the legacy and the updated (unsafe-evolution) memory-safety rules.