fix: resolve core library types in IL post-processing under .NET reference assemblies

[BrianUnity]

Purpose of this PR

When NGO's assemblies are compiled against .NET reference assemblies (for example when targeting .NET 10), the CodeGen post-processor cannot resolve core library types it imports through typeof().

PostProcessorReflectionImporter maps System.Private.CoreLib types to the module's mscorlib or netstandard reference. A module compiled against the .NET reference pack has neither: the pack splits the core library across System.Runtime, System.Collections and other assemblies. The imported type stays scoped to System.Private.CoreLib, and Resolve() returns null.

The fix: when the module references neither mscorlib nor netstandard, scope a System.Private.CoreLib type to the referenced assembly that defines or forwards it, with a per-type cache. Mapping everything to System.Runtime is not enough, because List<T>, for example, lives in System.Collections. Modules that reference mscorlib or netstandard take the old path, so existing builds are unchanged.

Entities and Multiplayer Tools have the same importer and get the same fix.

Jira ticket

None.

Changelog

com.unity.netcode.gameobjects

• Fixed: Issue where the IL post-processor could not resolve core library types, such as Guid and List<T>, in assemblies compiled against .NET reference assemblies, for example when targeting .NET 10.

Documentation

• No documentation changes or additions were necessary.

Testing & QA (How your changes can be verified during release Playtest)

Tested with a Unity editor that compiles packages for .NET 10, on a project with NGO's EditMode tests, Entities and Multiplayer Tools (all three with this fix):

• Before: compilation fails in IL post-processing.
• After: no compile errors, and NGO EditMode tests pass (1370 pass; 1 failure in BasicBuildTest, which is unrelated).

Builds that target netstandard take the unchanged code path.

Functional Testing

Manual testing :

• Manual testing done

Automated tests:

• Covered by existing automated tests
• Covered by new automated tests

Does the change require QA team to:

• Review automated tests?
• Execute manual tests?
• Provide feedback about the PR?

If any boxes above are checked the QA team will be automatically added as a PR reviewer.

Up-port

Not needed: this PR targets develop-3.x.x.

Backports

Not planned. .NET 10 targeting only applies to the newest editors, which use NGO 3.x. The importer on develop-2.0.0 differs only in its namespace, so the same change can go there if NGO 2.x needs it.