[test] Check for more -fsanitize=array-bounds behavior

...that had temporarily regressed with (since reverted)
<https://github.com/llvm/llvm-project/commit/886715af962de2c92fac4bd37104450345711e4a>
"[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible
arrays", and had then been seen to cause issues in the wild:

For one, the HarfBuzz project has various "fake" flexible array members of the
form

> Type                arrayZ[HB_VAR_ARRAY];

in <https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-open-type.hh>, where
HB_VAR_ARRAY is a macro defined as

> #ifndef HB_VAR_ARRAY
> #define HB_VAR_ARRAY 1
> #endif

in <https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-machinery.hh>.

For another, the Firebird project in
<https://github.com/FirebirdSQL/firebird/blob/master/src/lock/lock_proto.h> uses
a trailing member

>         srq lhb_hash[1];                        // Hash table

as a "fake" flexible array, but declared in a

> struct lhb : public Firebird::MemoryHeader

that is not a standard-layout class (because the Firebird::MemoryHeader base
class also declares non-static data members).

(The second case is specific to C++.  Extend the test setup so that all the
other tests are now run for both C and C++, just in case the behavior could ever
start to diverge for those two languages.)

A third case where -fsanitize=array-bounds differs from -Warray-bounds (and
which is also specific to C++, but which doesn't appear to have been encountered
in the wild) is when the "fake" flexible array member's size results from
template argument substitution.

Differential Revision: https://reviews.llvm.org/D128783