Check precise Windows GIX_TEST_IGNORE_ARCHIVES expectations on CI

[EliahKagan]

This modifies the CI test-fixtures-windows job introduced in #1657, by making it so that, instead of checking that no more than the expected number of test cases fail, it checks that the exact test cases expected to fail are the ones that do fail. (The other check done before as part of this job, that no tests report errors, is still done.) The approach taken is:

1. To collect actual failures, parse the XML output saved by cargo nextest to get the package name and test name of each failing test and save them, one per line, to a file.

   Getting this information is pretty straightforward in PowerShell. When iterating through testcase nodes, which are filtered by the presence of a failure subnode, $_.name gives the name of the test case, including :: qualifications within the containing package, and $_.classname gives the name of the containing package. Thus "$($_.classname) $($_.name)" identifies a test in the same way it is identified in human-readable cargo nextest output.

   The unintuitive attribute name classname is because cargo nextest XML is in the JUnit format, which originated for Java tests where test cases are methods in classes. An alternative approach is to use $_.ParentNode.name instead of $_.classname. I've verified that this works too, but I don't know of any strong reason to prefer one over another, so I went with the more compact $_.classname.

2. To collect expected failures, use gh (the GitHub CLI) to download the text of #1358, and parse the first ```text code block with regex, extracting the list of failing tests and saving them, one per line, to a file.

   One of the tests currently listed there, gix-ref-tests::refs packed::iter::performance, is a performance test that seems not to fail on CI (anymore?), though I still find it to fail locally. If it were to start failing on CI, we would want to know about it. So, before these changes, it was not included in the count. I've carried that over to the precise matching done here: tests that appear to be performance tests due to having performance in their names (not as part of any longer \w+ word) are not regarded as expected to fail.

   It is not obvious that the general approach of downloading the information from an issue is the best one. Although I like this approach and I think it's not too cumbersome, this is admittedly the less elegant step. Other approaches, including hard-coding the expected failures in the workflow or another file, could be used if this approach is not wanted.

3. To compare them, use git diff --no-index with various other options, printing the entire list of failures as context if they differ. The job fails if there are any differences.

   Because this neither a required check for PR auto-merge nor a dependency of one, I think failing not only if tests unexpectedly fail but also if any unexpectedly pass is unlikely to cause any significant problems, and that knowing whenever the set of failing tests changes in any way is worthwhile.

I intentionally excluded performance tests late in the process, so that there would be a commit whose CI results could be inspected that would verify that the check is capable of failing when the diff is nonempty (and that the output would display in a useful way, with effective colorization, etc., in this situation). That can be observed in this run output and compared to passing runs, such as the runs in this PR.

[Byron]

Thanks a lot for making this happen!

I am very impressed by what can be done with powershell, it clearly is .NET in a shell :).

And indeed, like predicted, reading the text block from the issue breaks isolation too much and is the reason I'd love to see these extracted into a file, for example if that's OK with you.

Thanks again.

[Byron]

Wonderful, thanks so much!