PyObjectAlloc no longer uses specialization and freelist is removed

[ijl]

The impl<T> PyObjectAlloc for PyObjectWithFreeList is an obstacle to
removing specialization. It is unused in all projects linked from
the README and within pyo3 itself, so let's just remove it.

[ijl]

cc #210

[konstin]

I have mixed feelings about this. It's true that it's an obstacle for compiling on stable and not widely used. OTOH it's a feature coming directly from the python c api and is relevant to performance. Would it be possible to feature gate with an off-by-default freelist feature?

[ijl]

Having the feature only benefits custom classes that choose to define it, and I don't see any in pyo3 or client projects. CPython classes are unaffected. If there is zero usage I think that suggest removing it. But I can look into a feature if you still prefer keeping it.

[kngwyu]

I'm against this change.
To remove default here means we can't override alloc/dealloc and I don't think it's a correct approach.

[konstin]

@kngwyu default doesn't work on stable, so we need to remove it someway. It's still possible to support overwrite alloc by using macro arguments.

@fafhrd91 you added the freelist; Do you know projects using that feature?

[kngwyu]

@konstin
But we have a custom dealloc implementation here https://github.com/rust-numpy/rust-numpy/blob/master/src/slice_box.rs#L67
So how about moving PyObjectAlloc's methods into PyTypeInfo?
If so we can still add custom alloc/dealloc implementations for a type which implements PyTypeInfo.

[konstin]

What would you think about this branch? Afaik that should work for all cases and we can even allow overriding with #[pyclass] later.

[kngwyu]

@konstin
Strongly 👍 for it!
This looks very natural solution to me.