Build tests prior to executing them - #4881

Running a single test from the inline Test CodeLens or the project
outline "Run Test" went through preTest, which builds the default (or
ALL) target. That is slower than necessary and, when a specific default
build target is configured, could leave the test's executable unbuilt so
the test could not run. This extends the targeted build-before-run added
in #4881 (issue #4515) -- previously wired only into the Test Explorer
run/debug handlers -- to the single-test entry points.

- Add CTestDriver.getTestBuildTargets(), reusing the same test-program ->
  executable-target mapping as buildTestTargets (extracted into a shared
  executableTargetNamesByPath helper). It returns no targets for test
  commands that are not CMake executable targets (e.g. python, cmake -E,
  or a nested ctest build-and-test).
- Thread an optional buildTargets list through CMakeProject.ctest() and
  preTest(); runTest() resolves the test's target and passes it, falling
  back to the default build when nothing resolves. All other ctest/preTest
  callers pass nothing and keep the existing default-build behavior.

* Fix Test Explorer and CodeLens test runs spinning forever

A test run launched from the Test Explorer or the inline Test CodeLens
created a vscode TestRun but only called run.end() on the happy path.
Any throw between createTestRun and run.end() (e.g. a build or ctest
failure) orphaned the run, so the progress spinner kept spinning
indefinitely even though the work had finished.

- Guarantee run.end() via try/finally at all three createTestRun sites
  (runCTest, runTestHandler, debugTestHandler). runCTest keeps
  propagating errors so task/workflow callers are unaffected; the two
  run-profile handlers log and finalize.
- Remove the now-redundant run.end() in coverageCTestHelper (the caller
  owns finalization) to avoid a double end().
- Await the run in the CodeLens handlers so failures are logged and
  surfaced instead of escaping silently, and route to the project that
  owns the test.
- Never collapse a single-test run to a match-everything regex when the
  full set of tests is unknown (empty superset); use exact anchored
  matches so one test can no longer trigger the whole suite.
- Log a warning when a requested test matches no discovered test.

* Report a clear reason when a CTest run produces no output

When a test was started but CTest returned no matching result -- for
example the test executable was not built (so CTest reports it as
"Not Run") or the run matched nothing -- the test was finalized with no
output attached, so VS Code showed a bare "The test case did not report
any output." This was especially confusing for projects like fmt whose
test executables are not built by the default target.

- Add reportMissingTestResult() to attach an actionable message ("the
  test executable may not have been built -- build the test target,
  then run again") to both the test output and its error state, in the
  non-parallel path and for explicitly targeted tests in the parallel
  path. Tests that genuinely ran and produced no output are unchanged.
- Harden CTest results parsing: decodeOutputMeasurement tolerates
  missing/empty values and failed decompression, and cleanupResultsXml
  no longer throws when a single test lacks Measurement/NamedMeasurement
  (which previously discarded the results of the entire run). Compressed
  (base64+gzip) test output continues to be decoded.
- Add a unit test and fixture covering compressed, missing and empty
  measurements.

* Build only the test's own target for single-test runs

Running a single test from the inline Test CodeLens or the project
outline "Run Test" went through preTest, which builds the default (or
ALL) target. That is slower than necessary and, when a specific default
build target is configured, could leave the test's executable unbuilt so
the test could not run. This extends the targeted build-before-run added
in #4881 (issue #4515) -- previously wired only into the Test Explorer
run/debug handlers -- to the single-test entry points.

- Add CTestDriver.getTestBuildTargets(), reusing the same test-program ->
  executable-target mapping as buildTestTargets (extracted into a shared
  executableTargetNamesByPath helper). It returns no targets for test
  commands that are not CMake executable targets (e.g. python, cmake -E,
  or a nested ctest build-and-test).
- Thread an optional buildTargets list through CMakeProject.ctest() and
  preTest(); runTest() resolves the test's target and passes it, falling
  back to the default build when nothing resolves. All other ctest/preTest
  callers pass nothing and keep the existing default-build behavior.

…rget (#5094)

Building tests before running them (#4881, for #4515) replaced the previous
per-folder default build with a targeted build of just the executable targets
behind the selected tests. When a test's CTest command is a wrapper program
rather than a CMake executable target -- "/usr/bin/bash" "-c" "mpiexec ...",
mpiexec, a Python launcher, or "${CMAKE_COMMAND} -E env ..." -- the program
cannot be mapped to a target, so it was dropped from the build list. If that
left no targets at all, buildTestTargets skipped the build entirely and CTest
ran against a stale or missing executable, which made cmake.buildBeforeRun
ineffective for those tests.

Such a test still normally runs something the project builds, so a selection
that cannot be fully resolved now falls back to the project's default build
instead of building nothing. Selections whose test programs all map to
executable targets keep the targeted build introduced by #4881.

…rget (#5094)

Building tests before running them (#4881, for #4515) replaced the previous
per-folder default build with a targeted build of just the executable targets
behind the selected tests. When a test's CTest command is a wrapper program
rather than a CMake executable target -- "/usr/bin/bash" "-c" "mpiexec ...",
mpiexec, a Python launcher, or "${CMAKE_COMMAND} -E env ..." -- the program
cannot be mapped to a target, so it was dropped from the build list. If that
left no targets at all, buildTestTargets skipped the build entirely and CTest
ran against a stale or missing executable, which made cmake.buildBeforeRun
ineffective for those tests.

Such a test still normally runs something the project builds, so a selection
that cannot be fully resolved now falls back to the project's default build
instead of building nothing. Selections whose test programs all map to
executable targets keep the targeted build introduced by #4881.

…rget (#5094)

Building tests before running them (#4881, for #4515) replaced the previous
per-folder default build with a targeted build of just the executable targets
behind the selected tests. When a test's CTest command is a wrapper program
rather than a CMake executable target -- "/usr/bin/bash" "-c" "mpiexec ...",
mpiexec, a Python launcher, or "${CMAKE_COMMAND} -E env ..." -- the program
cannot be mapped to a target, so it was dropped from the build list. If that
left no targets at all, buildTestTargets skipped the build entirely and CTest
ran against a stale or missing executable, which made cmake.buildBeforeRun
ineffective for those tests.

Such a test still normally runs something the project builds, so a selection
that cannot be fully resolved now falls back to the project's default build
instead of building nothing. Selections whose test programs all map to
executable targets keep the targeted build introduced by #4881.