[release/9.0-staging] ILC: Allow OOB reference to upgrade framework assembly

[github-actions]

Backport of #109988 to release/9.0-staging

/cc @sbomer

Customer Impact

• Customer reported: Possible System.Diagnostics.DiagnosticSource trimming issue #109872
• Found internally

Fixes a customer reported issue where the ILC build logic was making it impossible to upgrade FX assemblies via OOB references.

Regression

• Yes
• No

The inability to upgrade framework assemblies via OOB reference in ILC is not a regression, but changes in the particular OOB package the customer tried made this look like a regression when they upgraded to the latest version of this package.

Testing

Tested locally in a few different configurations:

• With the repro from Possible System.Diagnostics.DiagnosticSource trimming issue #109872, using IlcBuildTasksPath to point to a local build of the task. Validated ILC picks the 9.0.0 version of the referenced assembly.
• Using PackageReference to Microsoft.DotNet.ILCompiler version 9.0.0 in a net8.0 app (validated it doesn't break the ability to upgrade via manual PackageReference)
• Using PackageReference to Microsoft.DotNet.ILCompiler version 8.0.1 in a net8.0 app (validated it produces the expected error when trying to use System.Private.CoreLib from the coreclr runtime pack).

No automated tests were added because we don't have a good place for this kind of integration test (see discussion in #109988).

Risk

Low. The impact is limited to native AOT scenarios, and is targeted specifically at the scenario where a PackageReference introduces a conflict with a framework assembly. The new error only shows up in scenarios that were already broken, but turns an unpredictable failure mode (failure during ILC with an unhelpful error message about some implementation details) into a predictable one.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[jeffschwMSFT]

lgtm. we will take for consideration in 9.0.x

[ericstj]

Conflict resolution also checks assembly version first, but I don't think our current packages have any case where we might ship an older assembly version with newer file version (EG: newer package from lower servicing band). We used to - which is why that check in conflict resolution was required - but a single file version check should be good enough now since I think we give every assembly the same major.minor file and assembly version. Does that sound right @ViktorHofer?

[ViktorHofer]

The only exception that I know of in dotnet/runtime is System.Runtime.Serialization.Formatters

OOB 9.0.0 package assembly:

inbox 9.0.0 assembly:

There might be other packages, not sure. The above don't probably doesn't matter because only the inbox assembly has the difference, not the packaged-up assembly.