[BUG] Clearer commitment to public / stable API? (most importantly, type_caster)

At present, type_caster is something that exists in the py::detail namespace, but may be overloaded in downstream applications, either via a macro, or more directly.

A naive downstream example (that I wrote 😬):
https://github.com/RobotLocomotion/drake/blob/v0.25.0/bindings/pydrake/common/wrap_pybind.h#L54-L114
https://github.com/RobotLocomotion/drake/blob/v0.25.0/bindings/pydrake/common/cpp_param_pybind.h#L149-L158

At present, my reading of py::detail is that it's generally internal implementation details, i.e. it's internal, not public API, and should not be expected to be stable.

It seems like the base contract of py::detail::type_caster may more-or-less be leaked into a public details. We may want to consider making this more public, and having some level of public stability for this. In this way, we could hoist it outside of py::detail, so we could keep that reserved for truly internal details.

Possibly related:

• #2646 - holders (may be internal, but may motivate public contract for holder-type casters)
• #2732 - contract - exception handling
• #864 - mention backwards-compatibility, which mentions some semblance of stabliity

\cc @rwgk @YannickJadoul @rhaschke @wjakob

Start by reading the current py::detail::type_caster contract and the downstream examples in Drake's wrap_pybind.h and cpp_param_pybind.h. Review related issues #2646, #2732, and #864, then define the intended public-stability boundary and namespace before any implementation; the issue is done only when that decision and its compatibility implications are resolved.