[xtask] Attempt to handle CTS revision moving backwards

[andyleiserson]

As of #7800, if the git version is new enough that git clone supports the --revision option, the CTS xtask does the initial clone of the CTS repository shallowly, fetching only the desired commit of the CTS. Subsequent runs of the xtask will fetch the repository if the desired CTS commit is not present locally, which works when the desired commit is a descendant of the commit in the original shallow clone. However, it does not work if the desired commit is an ancestor of the commit in the original shallow clone.

In CI, we use GitHub actions caching feature to reduce repeated network fetches on each run. The CTS checkout is included in the cache.

Shortly after the v27 branch was created, the CTS version was bumped on trunk. This caused CTS jobs run on the v27 branch to fail (e.g. for 98caa62), because the GitHub actions cache contained a shallow clone of the CTS at a commit after the desired commit for the v27 branch. I fixed the immediate problem by changing the cache tag for the CTS jobs on the v27 branch (in 2ea52e0). This gave jobs running on the v27 branch their own git clones at the CTS commit used on the branch but would not do anything to prevent the same problem from occurring in the future. #8313 was filed for a better solution.

This PR fixes #8313 by adding an additional step to the xtask when cloning the CTS. Previously, the xtask fetched the CTS if it was not able to check out the desired revision. With this PR, it will still do that, but if the desired revision is still not available after fetching, it calls the GitHub API to determine if deepening the CTS clone can obtain the desired revision (and if so, by how many commits it needs to be deepened).

This seems like it will not be exercised very often, and could bit rot before it ever gets used. Feel free to say "just because you can, doesn't mean you should" and decline this PR.

Putting the branch name in all of our GitHub actions cache keys seems like a reasonable thing to do for various reasons, although doing so has some complications like getting PRs to use the cache for their target branch. Doing that would have helped in this case, but is not as general as the fix here, which would also handle developer checkouts switching between branches and cases where the CTS version moves backwards on the same branch (e.g. reverting a CTS version bump).

Other options are to fall back on a full fetch if the desired SHA is not found, or to delete/rename the clone and do a fresh shallow clone. (I find the latter undesirable because it can delete or hide work that a developer has done locally, although realistically, very few wgpu developers will be making changes to the CTS.)

Testing
Tested manually.

Squash or Rebase? Squash

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.