GeezerVison

This is a WIP/proof-of-concept of doing away with Py_TRASHCAN_BEGIN and
Py_TRASHCAN_END and instead integrating the functionality into
_Py_Dealloc.  There are a few advantages:

- all container objects have the risk of overflowing the C stack if a
  long reference chain of them is created and then deallocated.  So, to
  be safe, the tp_dealloc methods for those objects should be protected
  from overflowing the stack.

- the Py_TRASHCAN_BEGIN and Py_TRASHCAN_END macros are hard to
  understand and a bit hard to use correctly.  Making the mechanism
  internal avoids confusion.  The code can be slightly simplified as
  well.

This proof-of-concept seems to pass tests but it will need some careful
review.  The exact rules related to calling GC Track/Untrack are subtle
and this changes things a bit.  I.e. tp_dealloc is called with GC
objects already untracked.  For 3rd party extensions, they are calling
PyObject_GC_UnTrack() and so I believe they should still work.

The fact that PyObject_CallFinalizerFromDealloc() wants GC objects to
definitely be tracked is a bit of a mystery to me (there is an assert to
check that).  I changed the code to track objects if they are not
already tracked but I'm not sure that's correct.

There could be a performance hit, due to the _PyType_IS_GC() test that
was added to the _Py_Dealloc() function.  For non-GC objects, that's
going to be a new branch and I'm worried it might hurt a bit.  OTOH,
maybe it's just in the noise.  Profiling will need to be done.

Since _Py_Dealloc will untrack, don't need to do it in tp_dealloc.  If
an object is resurrected, PyObject_CallFinalizerFromDealloc() will do
the track call.

I'm not sure _PyType_IS_GC() is safe in case the object returns false
from tp_is_gc().