Add DISCOVERY_ENVIRONMENT option to catch_discover_tests

Closes #1810

Description

Test discovery runs the test executable in a separate process, which does not inherit anything set through PROPERTIES ENVIRONMENT — those are applied by CTest to the tests themselves, not to the listing run. An executable that needs a particular environment just to start up and list its test cases therefore fails at discovery time, even though the tests would run fine.

The cases reported in #1810 are a missing shared library search path, a Qt platform plugin needing offscreen on a headless machine, and an instrumentation library whose extra output corrupts the JSON listing.

DL_PATHS already solves this for dynamic linker search paths specifically, and its documented behaviour ("set when retrieving the list of test cases ... and when the tests are executed") is exactly the semantic people want here. This adds DISCOVERY_ENVIRONMENT for arbitrary <var>=<value> pairs.

catch_discover_tests(tests
                     DISCOVERY_ENVIRONMENT QT_QPA_PLATFORM=offscreen)

Scope decision

The option applies to discovery only, not to test execution. Every case in the issue is discovery-side — the tests themselves already ran correctly via PROPERTIES ENVIRONMENT. Making it discovery-scoped keeps the naming unambiguous and changes no existing behaviour. Happy to widen it to cover both if you would rather it mirror DL_PATHS exactly.

Restoring the previous environment

The variables are applied only for the duration of discovery and previous values are restored afterwards, including unsetting variables that were not previously defined. This matters in PRE_TEST mode, where catch_discover_tests_impl runs inside the CTest process — without the restore the variables would leak into the tests' environment, which is the opposite of what the option promises.

The saved values are kept in per-variable CMake variables rather than parallel lists, because an environment variable can be unset or hold an empty string and CMake lists cannot represent those two cases distinctly.

Testing

Added CMakeHelper::DiscoveryEnvironment, a pure-CMake unit test alongside the existing TestPrepareCommandFragment / TestDecomposeJsonArray ones. It drives catch_discover_tests_impl against a fake listing executable that reports a sentinel environment variable back through the test name, and asserts:

• the sentinel is unset when the option is not given
• the value reaches the listing process when it is
• the variable does not leak past discovery
• a pre-existing value is overridden during discovery
• a pre-existing value is restored afterwards

The fake executable is a cmake -P script rather than a shell script, so the test runs unchanged on Windows.

All five assertions pass locally, and the two existing CMake helper tests still pass. Note that I ran these via cmake -P directly; I have not built the full test suite, so the wider CI run is the first check of the tests/CMakeLists.txt registration.

Worth flagging: DL_PATHS and DL_FRAMEWORK_PATHS are documented in the Catch.cmake header comment but missing from the option list in docs/cmake-integration.md. I only added the new option there rather than fix that separately — happy to do so in another PR if useful.