Binplace System.Private.CoreLib into the testhost and runtimepack incrementally

[ViktorHofer]

A few months ago we switched from a named reference for System.Private.CoreLib to a ProjectReference so that we can build libraries without needing to build System.Private.CoreLib via the coreclr/mono.corelib subset first. This works as expected and improved the developer innerloop as CoreLib is now incrementally built as a dependency of libraries.

So far so good. We would now like to also binplace CoreLib incrementally into the testhost and runtime pack (as any other managed library under libraries) so that we don't need to invoke externals.csproj (libs.pretest subset) to update the testhost and the runtime pack. Basically we would like to switch from a pull to a push model to improve the developer innerloop workflow.

Why we haven't done this yet and what makes this less trivial are the following nuances:

1. CoreClr (and mono?) requires CoreLib's build configuration to match the native runtime bits. As an example, if coreclr.dll is compiled with the Debug configuration, CoreLib needs to be built in that configuration as well.
2. We currently pull the crossgend version of CoreLib when building libraries in Release. We would need to be able to crossgen CoreLib as a post-build step (ideally msbuild logic) conditionally (only in Release and not when measuring code coverage /p:Coverage=true). What makes this even more difficult is that we would need to make sure that crossgening CoreLib is fast and that crossgen itself is already built. Also crossgen vs crossgen2?

Raising this now as the Mono team asked for this actively and as it would improve the developer innerloop workflow: 792fd1d.

Related: #38034

cc @jkotas @ericstj @akoeplinger @safern @dotnet/runtime-infrastructure

[ghost]

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

[jkotas]

We currently pull the crossgend version of CoreLib when building libraries in Release.

I do not think this is useful to crossgen for developer inner loop. The inner loop should use non-crossgened CoreLib. Yes, it will make the inner loop different from the full stack build and test, and that's fine.

[ViktorHofer]

Yes, it will make the inner loop different from the full stack build and test, and that's fine.

I don't think this is useful for developer innerloop as well besides for perf measurements of incremental changes. If we don't care about that scenario too much, then I'm fine with not crossgening in incremental builds.

Unrelated, we still don't crossgen other shared framework libraries than CoreLib when testing in CI. So we are already inconsistent here.