Eliminate the 'runtime-portable' build

[tmds]

When we're source-building .NET, runtime gets built twice: once as runtime-portable, and then as (non-portable) runtime.

The runtime-portable is taking up a large chunk of the build time, and it would be a huge improvement if we can eliminate it.

This means that builds should accept the rid-specific packages instead of using the packages which are built with a portable name.

We must also guard the single runtime build preserves the built-from-source requirement.
It shouldn't output artifacts that were directly copied from the pre-built SDK and pre-built packages, like the app host and assets from runtime packages.

Tasks:

• runtime: support building from non-portable packages (source-build: support building runtime using non-portable runtime packages. runtime#75597)
• aspnetcore: support building from non-portable packages source-build: support building aspnetcore using non-portable runtime packages. aspnetcore#43937
• Microsoft.NETCore.App.Crossgen2: don't use pre-builts (Microsoft.NETCore.App.Crossgen2.sfxproj in source-build runtime#74721)
• ...
• add test

The test should do two passes. The first pass uses a portable pre-built SDK. The second pass uses the non-portable SDK that was the output of the first pass. This ensures source-build also works when starting with the non-portable SDK.

cc @MichaelSimons @crummel @omajid

[dotnet-issue-labeler]

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

[mmitche]

@tmds Am I correct to think that we should still allow for a only portable Linux source build, or an only RID specific build? Just that one the RID specific build should not depend on portable assets.

[tmds]

Fixed by dotnet/installer#14549.

@tmds Am I correct to think that we should still allow for a only portable Linux source build, or an only RID specific build? Just that one the RID specific build should not depend on portable assets.

@mmitche sorry for not picking up your question. Think of portable or non-portable as names, and the portable rid means it is supposed to work on a broader set of distros (because that's what the rid graphs describes).
When we run source-build, we expect to be provided the assets that correspond to the SDK rid. So if we're source-building using the orange.16-x64 SDK, we'll use the orange.16-x64 assets. And if we're using this SDK on Banana Linux 18, the corresponding SDK and assets that are produced are named banana.18-x64.