fix: 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.

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).

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.

[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?

[rwgk]

Suggested change

	# definePYBIND11_HAS_CXXABI_H
	// All supported Clang versions provide __has_include, but GCC versions before 5 do not.
	// Preserve the previous unconditional __GNUG__ behavior for those older, still-supported
	// GCC versions (see PR #6145).
	# definePYBIND11_HAS_CXXABI_H

This fallback is not self-explanatory and could, in principle, misidentify another GNU-compatible toolchain as providing <cxxabi.h>. I think it is important to document why preserving the old behavior is intentional for pybind11’s currently supported compiler range. It also leaves a useful hint for later: once pybind11 no longer supports GCC versions before 5, the fallback can be removed.

[aidaodedjl]

Pushed 0fee21e with the suggested comment verbatim above the fallback branch. The comment already carries the hint for later: once GCC < 5 support is dropped, the fallback branch can go too.

cpptest still passes locally (25 cases / 11285 assertions).