Support acquiring WindowsDesktop targets on-demand in non-Microsoft-built SDKs

It looks like for Windows Desktop we don't do the pluggable mechanism for WindowsDesktop like we do for other on-demand bits of functionality like AOT compilation or SingleFile compilation. The normal pattern is that framework references and other tools can be located in a number of locations:

* in the DOTNETSDK_WORKLOAD_PACK_ROOTS directory,
* in the user's HOME/.dotnet/packs directory,
* colocated with the SDK install root in the `packs` directory, and finally
* resolved from NuGet

This allows for different deployments of the SDK to still provide the same dependencies and logic, just with varying amounts of pre-packaging.

The WindowsDesktop bits do not appear to follow this pattern. While we do provide the packages for the reference assemblies and win0x86, win-x64, and win-arm64 runtime implementations, the SDK hard-codes an expectation that the WindowsDesktop targets will be colocated in the SDK layout [here](https://github.com/dotnet/sdk/blob/8ca5983e4462a95821a5f226b6f89a398112d2bb/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L1390-L1407). If we do expect users to be able to do some amount of compilation for the WindowsDesktop runtime on other platforms, then we will need to do some amount of work to make the WindowsDesktop feature set behave like our other FrameworkReferences.

cc @marcpopMSFT @dsplaisted

Attached is a binlog for anyone that would like to look at the problem.
[dotnet.zip](https://github.com/user-attachments/files/16228967/dotnet.zip)

_Originally posted by @baronfel in https://github.com/dotnet/core/discussions/9258#discussioncomment-10045661_