Don't build ReferenceSystemPrivateCoreLib tests with Mono

[lambdageek]

New tests that extend the System.Private.CoreLib API should add to the ref assemblies in src/libraries and the tests themselves should be library tests.

Updated the workflow doc: the Clr.Native subset is all that is need if we're interested in testing Mono.

Contributes to #58266

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

When building tests that reference System.Private.CoreLib, use the one from the specified RuntimeFlavor (or fall back to coreclr if it's unset - although src/tests/build.sh sets it always)

This means we only need to build the Clr.Native subset if we're interested in testing Mono.

Author:	lambdageek
Assignees:	-
Labels:	area-Infrastructure
Milestone:	-

[lambdageek]

Even better would be if there was a Clr.Run subset that just build corerun, but let's start with baby steps.

[jkotas]

for example while working on a new corelib API

The typical workflow for working on a new corelib API is to add it to reference assembly under libraries and then you do not need to worry about referencing corelib from tests at all, and you can also write the tests under libraries that is the preferred place for API tests.

I think we should be working on getting rid of the tests that reference CoreLib directly, no need to grow the hack.

[lambdageek]

I think we should be working on getting rid of the tests that reference CoreLib directly, no need to grow the hack.

👍