Work around GCC co_await bugs in test macros

[vasama]

Related GCC issues:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775

Related Catch2 issues:

• co_await expression inside REQUIRE may be run twice (GCC) #2591
• REQUIRE(co_await expr) unexpectedly repeats execution in GCC #2925

Use a volatile boolean to guard the unevaluated test expression instead of CATCH_INTERNAL_IGNORE_BUT_WARN (based on __builtin_constant_p, now removed).

I did not remove CATCH_CONFIG_USE_BUILTIN_CONSTANT_P, though it now seems to be unnecessary. It's unclear to me if removing it would break user configurations.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.33%. Comparing base (11a96e1) to head (5c8f9ec).

Additional details and impacted files

@@            Coverage Diff             @@
##            devel    #3092      +/-   ##
==========================================
- Coverage   91.36%   91.33%   -0.03%     
==========================================
  Files         204      204              
  Lines        8903     8903              
==========================================
- Hits         8134     8131       -3     
- Misses        769      772       +3     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vasama]

I had to add a variable initialiser in a test due to a now detected use of an uninitialised variable. Looks like the existing solution based on __builtin_constant_p was preventing some warnings from coming through.

[rajpratham1]

This looks like a nice simplification. Replacing the previous __builtin_constant_p/false && expression machinery with the volatileFalse pattern keeps expressions type-checked without evaluating them and avoids the GCC coroutine issue. The implementation is simpler and removes a fair amount of compiler-specific macro complexity. My only question is whether the removed IBM XL/NVHPC workarounds are still unnecessary with this approach, but assuming that's been verified, this looks good to me.