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

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.

In setuptools < 8.3 pkg_resources.py was a module, so

    import pkg_resources
    print(pkg_resources.__file__)

would print something like

    /home/mg/src/buildout/eggs/setuptools-8.0.4-py2.7.egg/pkg_resources.py

Starting from setuptools 8.3 pkg_resources became a package, so the
above code prints

    /home/mg/src/buildout/eggs/setuptools-11.3.1-py2.7.egg/pkg_resources/__init__.py

which means a single os.path.dirname() is no longer sufficient to find
the location of the .egg file/directory.

I'm pretty sure 'setuptools' itself was always a package, so use two
os.path.dirname()s on setuptools.__file__ to find the .egg location more
reliably with both old and new setuptools versions.

Fixes https://github.com/buildout/buildout/issues/227

  version-range requirements in a way that caused it to think there
  wasn't a single-version requirement.  IOW, buildout throught that
  versions were being picked when they weren't.

Should have been removed in a previous commit.

Setuptools8

On Windows, `sys.prefix` is a site-package directory, i.e. for a
standard installation `C:\Python27`. The code path for `not
allow_site_packages` removed *everything* from `sys.path` that contains
*any* of the the site-packages directories as reported by
 `site.getsitepackages`, which on Windows removes all pathes below
 `sys.prefix` from `sys.path`.

Add option to bootstrap.py to pin setuptools version

Merge branch 'pin_setuptools_in_bootstrap' of github.com:buildout/buildout into pin_setuptools_in_bootstrap

PKG-INFO for setuptools 3.3 has non-ASCII characters.  This causes
two test failures on Python 2, one of them rather unobvious
(testing_bugfix.txt complains about the different number of logging
handlers, of all things).

This simplifies testing all Python versions to 'tox'.

Unfortunately detox cannot be used to run the tests in parallel since
dev.py scribbles directly into the top-level of the source tree (in
bin/).

Tests with Python 3.4 passed on Travis, for a bit.

Contains fix for #198

Fix for the #198 fix

Should fix https://travis-ci.org/buildout/buildout/jobs/39918144

Closes #203

Some background: PEP 453 introduced the 'ensurepip' module to Python 3.4.
'make install' runs 'python3.4 -m ensurepip' which installs setuptools
into site-packages.  Our test suite doesn't like that.  Luckily,
Python's ./configure has an option to disable ensurepip.

Travis thinks something is wrong when the script produces no output in
10 minutes, which leads to sporadic test failures like
https://travis-ci.org/buildout/buildout/jobs/39916822

If PYTHON_VER is not known to the Makefile, don't fall back to
PYTHON_MINOR of 2.7.3, instead ask the user to specify a correct
PYTHON_MINOR explicitly.  Otherwise you get weird failures like #203.

Also allow the user to override PYTHON_MINOR on the `make` command line,
e.g.

    make PYTHON_VER=3.3 PYTHON_MINOR=3.3.6

Closes #202.