Should investigate usage of `py::wraper<>` trampoline shim with GC garbage collection (to prevent inheritance slicing)

Motivation

Towards #1333 (as part of the larger umbrella of #2646), this is meant to be my recording of investigating a py::wrapper<> shim trampoline with "resurrection" via the Python garbage collection.

Proof of Concept

I have a working proof-of-concept that is used for in a fork of pybind11 - see RobotLocomotion/pybind11:README_DRAKE.md.

The primary points to see are:

• Resurrection via GC: py::wrapper<>
• Additional mechanisms for holder ownership transfer to/from C++: py::class_<> methods (note: some of this is coupled to other issues mentioned in the fork README
• Tests: test_ownership_transfer.py, test_ownership_transfer.cpp

Drawbacks

• This approach is a bit messy, as it's from me "just making" things work for our library (Drake).
• As shown above, CPython 3.8 (and possibly 3.7.5+), we are unable to resurrect an object more than once.

Additional Notes

This may not be the best mechanism to prevent slicing. Willi be listing other mechanisms (i.e. PRs / suggestions from others).

External References

• CPython Object Model - object.__del__
• CPython Developer Guide - Additional Resources
  • Garbage Collector (permalink)
• CPython issue tracker
  • Issue 40240 - Expose (read-only) GC info
  • Issue 32377 - CPython 3.x GC ressurection got more picky

\cc @rhaschke @rwgk @YannickJadoul