Guard cxxabi.h include with __has_include for clang-cl

[aidaodedjl]

Description

clang-cl on Windows defines __GNUG__ but does not ship <cxxabi.h>, so detail/typeid.h fails with fatal error: 'cxxabi.h' file not found.

This introduces PYBIND11_HAS_CXXABI_H as suggested by @henryiii in #6129: defined only when <cxxabi.h> is actually available, using __has_include with a fallback for toolchains without it (pybind11 still supports C++11, where __has_include is not guaranteed). The macro guards both the #include <cxxabi.h> and the abi::__cxa_demangle call site in clean_type_id — guarding the include alone would leave the call undeclared.

Suggested changelog entry

Guard the <cxxabi.h> include with __has_include so that toolchains defining __GNUG__ without the header (e.g. clang-cl) can compile detail/typeid.h.

Fixes #6129

Verification

• Local (AppleClang, C++11): clean_type_id still demangles (N4demo3FooE -> demo::Foo) when the header is available.
• Forced-fallback build (macro path disabled): compiles and takes the erase_all branch without referencing cxxabi.h or __cxa_demangle.
• Full test suite green: cpptest 25 cases / 11285 assertions passed; pytest 1296 passed / 51 skipped (platform features) / 2 xfailed (pre-existing, Use std::hash<std::type_index>, std::equal_to<std::type_index> everywhere **except when libc++ is in use** #4319).

[aidaodedjl]

The macOS PyPy job aborted in PyPy's own _pypy_generic_alias builtin (SystemError: Bad internal call!) while pytest was collecting — stack is entirely inside pluggy/PyPy, no pybind11 frames. The Ubuntu PyPy job with the same change passed, and on macOS the new macro evaluates true so clean_type_id takes the identical code path as before this change. Looks like a PyPy flake; could someone with rights re-run that job?