Ideally we could suppress the warning locally in the `UNIQUE_NAME` macro,
but that runs into at least 2 issues:

1) Clang actually does not consider the warning as coming from inside the
   `UNIQUE_NAME` macro, even though it correctly points to its expansion
   as the problem. This means that adding `_Pragma`s inside the macro
   around the __COUNTER__ usage does not actually silence the warning.

2) Adding the local suppressions anyway breaks the expansion of
   `MAKE_NAMESPACE` macro inside the templated test case macros. This can
   be fixed for the newest clang version by removing its use and using
   the uniqued `TestName` for the namespace name directly, but this breaks
   compilation on GCC, and older Clang versions.

Because of these issues, we introduce global warning suppression for
`-Wc2y-extensions` to be done with it. We should revisit this if Clang 23
fixes the local pragma based suppression, when it might be worth the effort
to rework the templated test case macros to support it.

Closes #3076

Suppress `Global initializer calls a non-constexpr function 'Catch::makeTestInvoker' (i.22).`,
which is issued when using macro `TEST_CASE` for windows/MSVC builds.


---------

Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>

Fixes building on non-desktop GDK platforms.

Turns out that even in GCC, the expression in `__builtin_cosntant_p`
can end up evaluated and side-effects executed. To allow users to
work around this bug, I added a configuration option to disable its
use in internal macros.

Related to #2925

There is no reason to have code conditional on C++14, because C++14
is the minimum supported language standard for v3.

This was originally motivated by `REQUIRE((a <=> b) == 0)` no
longer compiling using MSVC. After some investigation, I found
that they changed their implementation of the zero literal
detector from the previous pointer-constructor with deleted
other constructors, into one that uses `consteval` constructor
from int.

This breaks the previous detection logic, because now
`is_foo_comparable<std::strong_ordering, int>` is true, but
actually trying to compare them is a compile-time error...
The solution was to make the decomposition `constexpr` and rely
on a late C++20 DR that makes it so that `consteval` propagates
up through the callstack of `constexpr` functions, until it either
runs out of `constexpr` functions, or succeeds.

However, the default handling of types in decomposition is to
take a reference to them. This reference never becomes dangling,
but because the constexpr evaluation engine cannot prove this,
decomposition paths taking references to objects cannot be
actually evaluated at compilation time. Thankfully we already
did have a value-oriented decomposition path for arithmetic types
(as these are common linkage-less types), so we could just
explicitly spell out the `std::foo_ordering` types as also being
supposed to be decomposed by-value.

Two more fun facts about these changes
 1) The original motivation of the MSVC change was to avoid
    trigering a `Wzero-as-null-pointer-constant` warning. I still
    do not believe this was a good decision.
 2) Current latest version of MSVC does not actually implement the
    aforementioned C++20 DR, so even with this commit, MSVC cannot
    compile `REQUIRE((a <=> b) == 0)`.

Xbox does not support getenv