clang-tidy review says "All clean, LGTM! 👍"

@daljit46 Open to feedback on how to best achieve this, given I'd like to combine it with #2821 before merging #2678.

Previously, this was slated to be achieved by adding an extra text file, which could be specified as the input argument to run_tests. With cmake this makes less sense: the test suite wasn't built from the ground up with ctest in mind, and so the direct translation from what we had to cmake is a little hacky given that origin (#2789 could hopefully help improve that a little), and the proposal here feels like exacerbating that. What's proposed here isn't a new set of tests; it's just a chosen subset of the existing tests. So I think what would better suit would be to create a new test label? This would be reasonably easy if the list of tests was explicit, but harder when it's grepped. #2789 would at least give each a more meaningful name for identification, but there'd still need to be a way to cross-check tests against this list as they are registered.

(On reading for the first time I also wonder if using labels to separate between C++ command / Python command / unit tests would be better than grepping on test names?)

If this suite of tests is under the category of "scripts", then I think it would make sense to place this under testing/scripts.

If we want to create a subset of an existing set of tests, then I think we need a way to parse a "label" for a test from a text file. Something like a comment or another syntax that tells us the specific label of the test. Then, we can easily run a specific set of test matching a label.
CMake does support labels as part of a test's properties, so we could make use of that (BTW I can't remember why I didn't add labels to our current tests, possibly because I intended to do it at a later point, but we definitely should do that regardless of this PR).

Given dc3566f in #2865 lists each test explicitly for cmake, it should be possible there to manually add a label to those tests of Python commands that are manually chosen to execute as part of CI, rather than relying on the interrogation of test shell script content. Since that is already listed as one of the tasks for #2865, I'm content to close this PR, though it will continue to serve as a reference for the set of tests that have previously been flagged as suitable for inclusion in CI.