WorkloadManifest.targets should be imported in a pre-determined order for `7.0`

[radical]

With the latest 7.0.0 sdk, the WorkloadManifest.targets for the wasm-tools* packs are imported in a different order from earlier which breaks the wasm workloads. We started hitting this with the stable branding change in dotnet/runtime.

In the working case:

• microsoft.net.workload.mono.toolchain.net6, microsoft.net.workload.mono.toolchain.net7, microsoft.net.workload.emscripten.net6, microsoft.net.workload.emscripten.net7

In the broken case:

• microsoft.net.workload.emscripten.net7,microsoft.net.workload.emscripten.net6, microsoft.net.workload.mono.toolchain.net7, microsoft.net.workload.mono.toolchain.net6

Mono.Toolchain.net*, and Emscripten*'s WorkloadManifest.targets are sensitive to the order, so we have a correct order specified in IncludedWorkloadManifests.txt.

We have been trying to fix this since the issue was discovered, but the solutions are non-trivial, and require a lot of non-trivial testing. It would be preferable to enforce the order in IncludedWorkloadManifests.txt. This would mean that all the testing that has been done, till we switched to stable branding, would still be relevant.
This change can be restricted to 7.0 .

cc @lewing @steveisok @marcpopMSFT @jonathanpeppers

[lewing]

I think this is much like the intent of #22358

[jonathanpeppers]

The way we've avoided ordering issues, is to put conditions like these on everything (especially properties):

$([MSBuild]::VersionEquals($(TargetFrameworkVersion), '6.0')) - .NET 6 Workload
$([MSBuild]::VersionEquals($(TargetFrameworkVersion), '7.0')) - .NET 7 Workload
$([MSBuild]::VersionEquals($(TargetFrameworkVersion), '8.0')) - .NET 8 Workload

But if there was a way to define the order, would could define a property like $(AndroidWorkloadImported) to check instead. And we wouldn't have bump these numbers each year.

[dsplaisted]

Fixed with #28627