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

[github-actions]

Backport of #109988 to release/8.0-staging

/cc @sbomer

Customer Impact

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

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 8.0.x