Use slngen tooling to generate solution file

[Arlodotexe]

Describe the proposed changes

Right now, we're using a PowerShell + a templated version of our previous (Visual Studio generated) solution file.

This is hard to extend and maintain. Instead, we should investigate using the slngen tool instead (see here).

Additional context

This will make CommunityToolkit/Tooling-Windows-Submodule#17 much easier.

[michael-hawker]

Looks like the shared projects are going to be an issue with slngen (both for the sample app heads and the tests), from #350:

"D:\a\Labs-Windows\Labs-Windows\common\CommunityToolkit.Labs.Shared\CommunityToolkit.Labs.Shared.shproj" (default target) (26) ->
(Build target) -> 
  C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VisualStudio\v17.0\CodeSharing\Microsoft.SharedProject.Common.targets(15,5): error MSB3871: Shared projects cannot be built on their own.  Please either build a project that references this project, or build the entire solution. [D:\a\Labs-Windows\Labs-Windows\common\CommunityToolkit.Labs.Shared\CommunityToolkit.Labs.Shared.shproj]

[michael-hawker]

Shared projects loading with new version now, though WinAppSDK tests not running, so not sure what's going on there...

[michael-hawker]

Huh, @Arlodotexe do running the WinAppSDK tests in the all solution work for you? Wonder if something happened and we need to update to the latest (part of the PR I was doing for #183...).

I tried on another branch without slngen and it didn't seem to work. Will check the CI when I update my PR for #350.

[michael-hawker]

Think main limitation now is the platform configuration generation in slngen, see microsoft/slngen#437 and a nice-to-have: microsoft/slngen#438

Our current solution's config for reference in future:

ARM/ARM64 missing is the biggest issue.