Allow custom allocators for PyObject memory

[nascheme]

The current API allows a lot of flexibly in how PyObject memory is allocated. It can be statically allocated (non-heap types, for example), allocated with CPython's allocator or allocated with some custom allocator (provided by the extension module). This flexibility must provide some advantages (I'm not really sure what they are exactly) but it also places a pretty significant constraint on the implementation of Python. Typically in a garbage collected language implementation, object memory is allocated by the runtime. For best performance, the garbage collector is intimately familiar or integrated with the object allocator. This can reduce memory overhead per-object and speed up the GC process.

We should decide if this is a required feature of the API. An alternative would be to require that PyObject memory be allocated by the runtime (which is already the case for objects with PyGC_Head). Hopefully people with compelling use cases for custom allocated can comment and explain their situation.

[gvanrossum]

This is particularly relevant since noGIL (currently) relies on mimalloc, making custom allocators either impossible or at least expensive to use. I presume something like Python's own tracemalloc continues to be used. But just providing three pointers to alternative implementations of malloc, free and realloc? That may be a challenge.