tracemalloc in objects destructor

Replace atexit handler with an harcoded C function _PyTraceMalloc_Fini().

causing test_multiprocessing_forkserver and test_multiprocessing_spawn
failures on head (3.4).

causing test_multiprocessing_forkserver and test_multiprocessing_spawn
failures on head (3.4).

descriptor 0, 1 or 2 is closed.

descriptor 0, 1 or 2 is closed.

This fix does not cause any degradation in performance.

MvL would like to be able to preserve CPython's existing clean
uninstall behaviour on Windows before enabling the pip
installation option by default.

This private CLI means running "python -m ensurepip._uninstall"
will remove pip and setuptools before proceeding with the rest
of the uninstallation process.

If the version of pip differs from the one bootstrapped by
CPython, then the uninstallation helper will leave it alone
(just like any other pip installed packages)

that don't require changing test.test_importlib.util.mock_modules().

module loaders.

Due to the fact that the call signatures for extension modules and
built-in modules does not allow for the specifying of what module to
initialize and that on Windows all extension modules are built-in
modules, work to clean up built-in and extension module initialization
will have to wait until Python 3.5. Because of this the semantics of
exec_module() would be incorrect, so removing the methods for now is
the best option; load_module() is still used as a fallback by
importlib and so this won't affect semantics.

PyTuple_New(0) always returns the same empty tuple from its free list anyway,
so we are not saving much here. Plus, the code where this was used is on
uncommon run paths.

I have noticed a race-condition occurring on one of the buildbots because of
this optimization. The function called may release the GIL which means
multiple threads may end up accessing the shared tuple. I could fix it up by
storing the tuple to the Pickler and Unipickler object again, but honestly it
really not worth the trouble.

I ran many benchmarks and the only time the optimization helps is when using a
fin-memory file, like io.BytesIO on which reads are super cheap, combined with
pickle protocol less than 4. Even in this contrived case, the speedup is a
about 5%. For everything else, this optimization does not provide any
noticable improvements.

Based on patches by Christian Heimes and Vajrasky Kok