CodeHealth: Enabling clang-tidy google-explicit-constructor

[rwgk]

Description

The main change is the one-line addition of google-explicit-constructor in .clang-tidy:

https://clang.llvm.org/extra/clang-tidy/checks/google-explicit-constructor.html

This enforces the use of explicit, unless disabled with NOLINT. In other words, bug-prone implicit conversions are made opt-in rather than opt-out.

Apart from the entertaining #ifdef in include/pybind11/functional.h, the rest of this PR is extremely dull. It is the result of ~20 iterations of running clang-tidy, and manually sorting through the automatic changes, inserting

// NOLINTNEXTLINE(google-explicit-constructor)

as needed. Final change stats are:

• 27 explicit added under include/pybind11/
• 46 NOLINT added under include/pybind11/
• 92 explicit added under tests/
• 0 NOLINT added under tests/

The only code changes beyond these are in tests/test_smart_ptr.cpp, one of them

-    m.def("make_object_2", []() -> ref<Object> { return new MyObject1(2); });
+    m.def("make_object_2", []() -> ref<Object> { return ref<Object>(new MyObject1(2)); });

and two similar changes.

It is possible that some NOLINT under include/pybind11/ could be removed, with corresponding code changes elsewhere, but those are likely more involved and best left for separate PRs, so that they don't get drowned in the sea of boilerplate changes under this PR.

Suggested changelog entry:

The clang-tidy ``google-explicit-constructor`` option was enabled.

PR #3250 added a number of explicit keywords to improve general code health. It is not expected that this affects user code, but it is a possibility. Insert explicit constructors in your code as needed, or if that is not feasible, please send a PR to replace the problematic explicit keywords with // NOLINTNEXTLINE(google-explicit-constructor) directives, including a unit test reflecting your use case.

[rwgk]

Thanks Aaron!

I added a small paragraph for the upgrade guide to the PR description.