Finished MultiTarget support for solution generation

[Arlodotexe]

This PR leverages prior improvements to tooling made in #169 to finish fleshing out MultiTarget support for our generated solution:

• Now takes MultiTargets parameter instead of IncludeHeads, fully aligned with the rest of our existing system.
• Only includes deployable heads and tests for the MultiTargets provided.
• If no head is found for a requested target (as it will for all but Uwp, Wasdk and Wasm), it is silently skipped and the solution will generate regardless.
  • This works even if no heads end up in the solution, which was important for creating a clean GitHub Actions matrix setup based on possible MultiTarget values.
• Fixes to the underlying GenerateAllProjectReferences.ps1, GenerateMultiTargetAwareProjectReferenceProps.ps1 and UseTargetFrameworks.ps1 scripts required to support the above changes and a multitarget CI matrix
• Project references are only generated if the component supports one of supplied MultiTargets, in addition to the existing multitarget-aware conditional project references. This prevents a head from referencing a component that doesn't support the head's TFM or has that multitarget disabled.
• A head is only added to the solution if there's a project that MultiTargets it, preventing errors about an empty sample registry.
• The ExcludeMultiTargets property is now used in all our tooling scripts, not just those introduced in Add new build scripts, minor cleanup #169. (no more all-uwp!). Required to support a multitarget CI matrix.
• A Components parameter can be provided, and only the specified components will be included in the generated solution.
• A WinUIMajorVersion (aliased to winui) parameter can be provided and is applied automatically. This is for switching between Uno/WinUI 2 and Uno/WinUI 3 under the same TFM and will be important if UWP and Wasdk ever use the same TFM, but is otherwise a nice-to-have for toolkit developers.

We're considering what it would take to move our tooling into reusable packages in the future, and the improvements in this PR touch on alignment and standardization that is necessary for the kind of stable long-term setup we want for our tooling in any reuseable third-party context, whether as a submodule or a set of packages. Other potential high-value tooling improvements that play off the changes here will be fleshed out and filed in a future GitHub issue.

[michael-hawker]

Couple of small comments, looks like some comment/help text got changed with a find/replace, so should just review that at least. Thanks!