Replaces #204, fixes #30.

A date leads to less confusion than a version number separate
from buildout's own version number. Similarly, tracking buildout's version
number leads to bootstraps with a new version number but without changes or to
bootstraps with version number from an already-older buildout. So: a date is
best.

I don't think many people use this option as it isn't documented.
It used to be handy around the time when we had lots of breakage.
Nowadays it isn't needed.
So... I'm moving it out of the way to make room for --version as a proper version-returning option.

This is an urelated change from mgedmin's #204 pull request.
Prefixing is good as it might help figuring out what keeps filling up a temp
dir in case there's a problem.

See #86 and #222

Travis speed improvement through caching

There is code in buildout to remove develop-eggs that it knows about.
So if everything is OK, develop-egg removal works fine.
If there's something fishy goign on, however, buildout
doesn't clean it up enough. Zapping the entire directory upon bootstrap
is a very effective way to prevent problems.

Reason: the old osc.recipe.sysegg did add develop-eggs .egg-link files to the
site-packages dir, effectively short-circuiting buildout's picked versions.
Likewise an old bootstrap could have left a setuptoos.egg-link to an ancient
setuptools version. I just this minute had to help a colleague with just such
a problem.

The only effect of the import is that ez_setup's use_setuptools() function
does a sys.exit(2) when the required version doesn't match the site package's
one.

If the import doesn't happen, use_setuptools() will just grab a matching
version if the site package's version is too old.

Note that the latest ez_setup.py scripts default to requiring the very latest
setuptools version! So --allow-site-packages isn't really very useful this
way.

The python 2/3 try/except for urlopen() was combined with an optional import
of setuptools and pkg_resources.

The end result is that IF you're on python2 and IF you use
--allow-site-packages and IF you don't have setuptools installed, THEN you'll
get an import error for the python 3 urlopen...

All options' help text now start with a capital letter.

(Good test to see if it improved travis' speed!)

The cache mechanism of travis-ci.org itself creates the cache directory, so it
is already there before we try to add it.
The bin/python inside it seems a good target.

Disabling sudo enables the use of the container based infra, necessary for
caching.
The directory with the downloaded and compiled python is cached.

Use local ez_setup.py if one exists; add --setuptools-download-base option

The pull request itself contains a change that should not be applied.

Run easy_install with specified setuptools_version, same change as #232 

Run easy_install with specified setuptools_version

Use 'rcN' for release candidate versions in tests

Our VersionConflict handling could result in an UnpackError when rendering

Potential fix for https://github.com/buildout/buildout/issues/217

If setuptools is installed globally by easy_install then the easy_install.pth gets added to sys.path before PYTHONPATH and the wrong setuptools version is used.

Recent setuptools versions changed the canonical spelling of release
candidate versions from 'cN' to 'rcN'.  Using the older spelling causes
a UserWarning about the version requiring normalization, and test
failures where the expected output contains a different (normalized)
version number.

For the record, the UserWarning looks like this:

/home/mg/src/buildout/eggs/setuptools-11.3.1-py2.7.egg/setuptools/dist.py:283:
UserWarning: The version specified requires normalization, consider
using '1.2rc1' instead of '1.2c1'.

and the failures can be seen at
https://travis-ci.org/buildout/buildout/jobs/46215472

Don't assume pkg_resources is a module.