feat: drop C++11 support, require C++14 or newer

[henryiii]

🤖 AI text below 🤖

Description

Drops C++11 support, making C++14 the minimum. This is the smaller subset of #6124 (which also drops C++14).

First commit removes the C++11 code paths:

• detail/common.h gets a clear #error below C++14; the hand-rolled enable_if_t-style aliases and the recursive make_index_sequence implementation are replaced with the std versions; overload_cast and [[deprecated]] become unconditional; Intel minimum is now v19 (v18 was kept only for C++11).
• detail/init.h factories always use lambda init-captures (move instead of copy).
• CMake requires cxx_std_14 on the interface target; setup_helpers rejects cxx_std below 14; CI C++11 jobs move to C++14. Two cmake-build tests verify a consumer requesting C++11 is promoted.

Second commit simplifies internals with C++14 features: return type deduction removes the PYBIND11_READABLE_FUNCTION_SIGNATURE_EXPR macro, relaxed-constexpr loops replace the constexpr_impl recursion helpers and the __cpp_fold_expressions split in constexpr_sum, std::make_unique and the std::*_t alias templates are used where the meaning is unchanged. conduit/ is intentionally untouched (stays C++11-compatible), as is the func_wrapper extension point.

Third commit enables the clang-tidy checks modernize-make-unique and modernize-use-transparent-functors (both need C++14) and applies the fixes in the headers and tests.

Suggested changelog entry:

• Support for C++11 was removed. C++14 or newer is now required.

---

📚 Documentation preview 📚: https://pybind11--6149.org.readthedocs.build/

[Skylion007]

Doesn't really seem as worth it compared to CPP17 update

[rwgk]

Doesn't really seem as worth it compared to CPP17 update

Yeah, the "unshackling" aspect really only comes with dropping CPP14, too.

But I'm still highly supportive of this work, as a stepping stone.

When dropping CPP11 is done, we should evaluate if we want a release before also dropping CPP14, or plow through.

[henryiii]

The benefit is there's virtually no drawback to this. You can support the full macOS version range, for example (meaning you can still build with cibuldwheel's default settings). I think this could easily go into a 3.2 release, while C++17 we've been discussing making a 4.0 release and LTS'ing support for 3.x (which doesn't sound attractive, TBH).

And this drops over 100 lines, simplifies a few hundred more, makes overload_cast just work everywhere, and reduces our testing a bit.

Yes, not as good as 17, but not as trivial a cleanup as it seems (we hit a lot of edge cases that got fixed in C++14).

[henryiii]

I'm waiting on pretty much any changes, though, till we get the pre-compile stack reviewed! Don't want to have to keep rebasing it, triggers a huge amount of CI.