Don't include <stdatomic.h> in C++

OPENSSL_C11_ATOMIC is both computed in crypto/internal.h and also
defined externally. This is a remnant of C11 atomics were an opt-in
feature.

If defined externally, this means OPENSSL_C11_ATOMIC might be defined
when built as C++. That, in turn, causes <stdatomic.h> to be included in
C++ mode. At least one of our users toolchains has a <stdatomic.h> that
is incompatible with C++.  We don't get anything out of including it, so
just gate the include on !defined(__cplusplus) for now.

Things to look into as follow-up:

- Fix build files to stop defining OPENSSL_C11_ATOMIC. Prior to
  https://boringssl-review.googlesource.com/c/boringssl/+/59847, it was
  still serving a purpose: in server builds, if autodetection fails, we
  would rather fail to build than accidentally fallback to locks.
  There is no lock fallback anymore.

- Fix that toolchain so their <stdatomic.h> is C++-compatible. It's
  certainly not C++23-conformant. I suspect it's also not
  C++11-conformant, but I'm not positive.

Change-Id: I13bcd8380efeb87b9f9cc439fe24a743e48aec60
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

crypto/internal.h

@@ -165,6 +165,10 @@
 #define OPENSSL_C11_ATOMIC
 #endif
 
+#if defined(OPENSSL_C11_ATOMIC)
+#include <stdatomic.h>
+#endif
+
 // Older MSVC does not support C11 atomics, so we fallback to the Windows APIs.
 // When both are available (e.g. clang-cl), we prefer the C11 ones. The Windows
 // APIs don't allow some operations to be implemented as efficiently. This can
@@ -176,10 +180,6 @@
 #endif
 #endif  // !__cplusplus
 
-#if defined(OPENSSL_C11_ATOMIC)
-#include <stdatomic.h>
-#endif
-
 #if defined(OPENSSL_WINDOWS_THREADS) || defined(OPENSSL_WINDOWS_ATOMIC)
 OPENSSL_MSVC_PRAGMA(warning(push, 3))
 #include <windows.h>