fix(ci): restructure custom libc++ wrappers to include_next first

The previous approach renamed the custom copy's include guards
(_LIBCPP_*_H -> _LIBCPP_CR_*_H). That fixed the v8/ICU compile layout,
where the toolchain's own libc++ 21.1.8 copy follows in the include
search path and still defines the standard guards - but it broke the
libcxx runtime build itself: that build has no toolchain libc++ copy,
so <cctype>/<cwctype> from src/system_error.cpp never found libc++'s
<ctype.h>/<wctype.h> and the self-check #error fired.

Restructure all 13 C-compat wrappers uniformly to libc++'s own
include_next-before-guard pattern (as <wchar.h>/<stdio.h>/<stddef.h>
already use): the include_next runs first, then the wrapper defines the
STANDARD-named guard. In the v8/ICU layout the toolchain copy runs and
defines the guard (or the custom copy does if it lands there); in the
runtime layout the custom copy defines it. Both layouts satisfy the
<cctype>-style checks and the chain always reaches glibc/musl.

Files: complex.h ctype.h errno.h fenv.h float.h inttypes.h math.h
stdatomic.h stdbool.h string.h tgmath.h uchar.h wctype.h. math.h drops
its MSVC-only _USE_MATH_DEFINES #else branch (never reached on our
targets); uchar.h keeps its has_include_next fallback and defines the
guard after the whole block.

Validated with a local g++ harness replicating both CI include layouts:
patched headers compile in the with-toolchain-copy and without it, and
the unpatched control reproduces the original unresolved-symbol errors.
The patch was applied in a git-initialized checkout mirroring bazel's
patch step (a stray .git in a parent directory previously made git apply
skip silently).

Author: KooshaPari