[FEAT] keep_alive_impl should admit reference cycles, and ideally be released by GC?

Upstream motivation - memory leaks that don't get released:
https://github.com/RobotLocomotion/drake/issues/14387

Basically, because of our usage of unique_ptr and how we've design our C++ public API and bindings (https://github.com/RobotLocomotion/drake/issues/13058), there are some awkward edge cases when we have "opaque" memory transfers.

This arose because we wanted to fix a segfault: https://github.com/RobotLocomotion/drake/pull/14356
However, this reference cycle appears to grow without bounds.

TODO(me): Explicitly try gc.collect() with aggressive collection arguments.
See below: https://github.com/pybind/pybind11/issues/2761#issuecomment-752777742

I'm filing this now because @YannickJadoul mentioned that keep_alive may be useful for #1941 (py::dynamic_attr coordinating with "mismatched" lifetime between py::detail::instance and the actual shared_ptr<T>). A keep_alive may fix that issue in a more general way, but will admit reference cycles

Note: I am speculating that the current approach (based on Boost.Python, per @bmerry's comment in #880) doesn't admit GC collection when cycles are introduced. I should confirm this.

\cc @rwgk @rhaschke about this sharp edge case with unique_ptr<> (#2646)