Enable AOT-compiled SDK tools when the SDK is built via source-build

[mthalman]

Motivation

We want to ship AOT-compiled SDK tools as part of the .NET SDK. The first concrete example is dotnet-user-secrets, where AOT-enablement is being applied in dotnet/aspnetcore#66663.

For this to be viable, AOT publishing needs to succeed in every build of the SDK we ship, including the VMR's source-build legs and downstream distros' source-build runs. Today, it doesn't. Surface symptoms depending on configuration:

• PublishAot=true with the default portable RuntimeIdentifiers list: restore fails with NU1102: Unable to find package Microsoft.NETCore.App.Runtime.linux-x64. Source-build doesn't publish runtime packs under portable RID names.
• Scope RuntimeIdentifiers to the build's non-portable RID via $(TargetRuntimeIdentifier): restore succeeds, then the SDK rejects the project with NETSDK1203: Ahead-of-time compilation is not supported for the target runtime identifier 'centos.10-x64'.

What's blocking this from working

Every repo's build in the VMR is invoked against a previous SDK version. In a stage 1 source-build leg that SDK is the Microsoft-built portable SDK, which has none of the configuration the source-built SDK output ends up with:

• Its Microsoft.NETCoreSdk.BundledVersions.props does not include the build's non-portable RID in ILCompilerRuntimeIdentifiers or RuntimePackRuntimeIdentifiers.
• Its packs/ folder does not contain the NativeAOT runtime pack for the build's RID.

So, for example, when aspnetcore builds dotnet-user-secrets with PublishAot=true for the build's non-portable RID, the previous SDK's ProcessFrameworkReferences task validates the target against its KnownILCompilerPack.ILCompilerRuntimeIdentifiers using PortableRuntimeIdentifierGraph.json (no non-portable entries), fails the lookup, and emits NETSDK1203. The source-built SDK that this build will eventually produce would accept the same target, but it doesn't exist yet at the point where aspnetcore is being built.

The stage 2 leg is the inverse: it uses stage 1's SDK output as its dependent SDK, so the AOT configuration and bundled AOT pack are present and AOT-publishing dotnet-user-secrets against it would succeed.