Confused static assertion implementation

Hi,

I won't be surprised if Peter (CC'd) already has a patch for this in
his C11 incubation branch, but if not, maybe this will be useful.

While experimenting with threads and atomics on various systems, I
didn't like the way our macros failed in the ancient fallback code on
Visual Studio. That only seems to be necessary for
StaticAssertExpr(), the rarest case. That led to some observations:

* the meson script defines HAVE__STATIC_ASSERT if you have GCC
statement expressions, so why not just say so with
HAVE_STATEMENT_EXPRESSIONS, and keep ye olde fallback only for
StaticAssertExpr()?

* the configure script is different, tautological and wrong for
(evidently hypothetical) non-GCC-compatible C11 compiler given the
above interpretation of the macro

* to my knowledge we haven't written down which C++ standard our
headers conform to anywhere, but it surely can't be older than C++11
(I could elaborate), so I don't think we need the two __cplusplus
implementations

Here's an attempt to tidy that up.

We could also consider allowing ourselves to use standard
static_assert() directly in new code, in scopes that accept
declarations (eg file top-level, inside structs, inside functions as
allowed by our self-imposed -Wno-declaration-after-statement rule),
but that's essentially an independent question and I can also see that
the inconsistency might be annoying, cf size_t/Size, uint64_t/uint64,
etc debates with different outcomes. For reference, we currently have
84 "...Decl", 10 "...Expr", and 18 "...Stmt" occurrences in the tree,
and if that has any predictive power, the vast majority of new code
would likely just use static_assert().

. o O { I wonder if it's possible to write a C23/C++17-compatible
single-argument static_assert() macro, or if you'd get stuck in a loop
and need to use a different name... the message argument is so often
boring/redundant... }