Enable WinUI Controls Test Pipeline

[PureWeen]

Description of Change

Enables the Controls projects device tests for Mac Catalyst. A couple of things to note:

• Due to limitations/bugs on the WinUI side we need to run these in chunks. Running all tests at once will make the application crash. For the time being running each category separately works fine. The code implemented for this isn't great, but it works. We will follow up with the WinUI team to see if we can find a cause and make it better. Eventually we can offload some of the (potentially crashing) tests to UI tests as well which might help.
• We've disabled a number of tests to make this PR green for now, we need to revisit those and either adjust the test or the functionality.

How These Tests Get Executed / Good To Know

Because we run the tests for Controls per category, that also means the test results are divided as such. On top of that, the Windows app knows two variations: packaged (distributed through an MSIX typically) and unpackaged (more traditional exe + dlls). Because of this combination the flow of tests is a bit different than the rest.

Because tests are ran by category, each test should be in a category. Tests that are not in a category will be ran with each test run.

• Keep in mind that the windows.cake script is used for all projects so also Core, Graphics, etc. and only this project, Controls, needs special treatment. Therefore there is some logic added in the Cake script to differentiate between Controls and the rest. To this end the Cake script has a variable isControlsProjectTestRun that checks if the project to be tested ends with Controls.DeviceTests.csproj.
• The Controls test runner can now be started with an additional command-line argument. The first argument, which existed, is to provide the path for the test results, the second parameter, added in the PR, specifies the loop count. The loop count is provided by the Cake script.
• When the Controls test runner is started with a loop count of -1, it will do some reflection on the test assembly to pull out the categories that are defined. Those are written to a txt file so that the Cake script can read it and determine the right loop count for the test runner.
• From there, the actual testing starts. For 0 to {category count} the test runner is now started and the loop count is upped for each one. Each loop, for a packaged app, has a 10 second timeout. This is arbitrary and seems good enough for now. This is because packaged apps can only be started through PowerShell and going through Cake, to cmd, to PowerShell to a deployed app it seems impossible to block the thread to wait on it. Unpackaged apps do block the thread and run sequentially. To support all this there is a dedicated ControlsHeadlessTestRunner in the Windows test runner that is only used for the Controls project when running headless.
• For each of the loops a test results file is written based on the command-line argument from above, but the category name is added to the filename. This does mean that in the Tests tab in Azure DevOps (and in the artifacts of the build) there will be a lot of test result files: one for each category for the packaged app, one for each category for the unpackaged app. That means that is there are 40 categories we will have 80 test results files in total.
• This is not specific to this change, but for the device tests we automatically retry on failures to prevent flaky test results. This does mean that if something fails and is retried, that you might end up with 40 categories times 2 (for (un)packaged) and then times the number of retries. That makes the results a bit hard to parse. All the more reason to not have any tests fail.
• To determine if any test has failed in any of the test result files we loop through the TestResults-*.xml files and do an XPath query to see if there is a failed count of > 0. If there is, we throw an exception from the Cake script to fail the pipeline.
• When a process crashes the test result file is not written. To detect that we compare the number of categories that are written to the txt file from above to the test result files that are written by the test runners. If they don't match the build is failed.

Issues Fixed

Related to #11236

[PureWeen]

/rebase