python: 2.7.9rc1 devel

ensurepip is backported to 2.7.9; use that to get pip instead of staging pip and setuptools ourselves.
> A few reasons not to use it, probably in order of descending importance, are:
> 
> 1) With ensurepip, we risk downgrading pip on post-install since pip and CPython have different release cycles and the bundled version ensurepip uses is only updated at each CPython maintenance release.
> 
> If we resource them ourselves we still force a version of pip and setuptools at post-install but at least we get to bump those independent of a CPython release.

I'm not super concerned about this, personally. I think defaulting to upstream behaviour beats having the latest version of the package.

> 2) ensurepip can't be made to ignore user configuration in ~/.pydistutils.cfg. These are probably rare in practice but could lead to surprising outcomes.

We can (temporarily) override `ENV["HOME"]` to handle these types of cases.

> 3) We also need to make sure we have setuptools; ensurepip presently installs setuptools as a pip dependency (and that will work until at least the next CPython release) but we're supposed to consider that to be a private implementation detail that may change.
> 
> TLDR-y segue on why we have to remove old pips before using ensurepip:
> If pip can be imported, ensurepip won't do anything; it doesn't check if the scripts exist in /usr/local/bin or not. The way we've installed pip before, when a user upgrades python, pip is importable after unlinking the old python but the scripts are gone. So, ironically, just using ensurepip leaves us without a "pip" command. So we have to forcibly remove any existing pip first.

Ok, cool.

Ultimately it's up to you; you know more about this side of things so I want to provide input rather than major objections or anything. I do think it'd be good to sync up the approaches between `python` and `python3` but that can be another PR.