Even though such configuration is wrong...

Currently only zc.recipe.egg:custom supports setting environment
variables, and zc.recipe.egg:develop does not.

My motivation for allowing setting environment in :develop is
wendelin.core

    https://lab.nexedi.cn/nexedi/slapos/blob/b5faab3b/component/wendelin.core/buildout.cfg

There we have [wendelin.core] part which installs released egg from
pypi, and [wendelin.core-dev] part which installs wendelin.core from
its latest git version via zc.recipe.egg:develop .

The problem is, wendelin.core for setup.py to work, needs git available,
and with slapos we usually don't have git available on base system, so
we build it by our own and do something like

    [wendelin.core-dev]
    recipe = zc.recipe.egg:develop
    environment = wendelin.core-dev-env

    [wendelin.core-dev-env]
    # wendelin.core-dev needs git to build
    PATH = ${git:location}/bin:%(PATH)s

and the problem is environment does not currently work for
zc.recipe.egg:develop, and thus git is not found -> build fails.

~~~~

In order to support environment in :develop, we just move environment
setting/restoring bits from Custom to Base, and provide Base.install() which
uses this bits. Custom & Develop .install() becomes ._install() which gets
hooked into Base.install() .

I've tested the patch only manually, because currently automated tests are
broken in a lot of places for slapos.buildout and zc.recipe.egg .

/cc @kazuhiko, @Tyagov

- Support on the fly patches in zc.recipe.egg by ``EGGNAME-patches``,
  ``EGGNAME-patch-options``, ``EGGNAME-patch-binary`` (or
  ``patch-binary``) and ``EGGNAME-patch-revision`` options.

- Support on the fly patches in zc.recipe.egg:custom by ``patches``,
  ``patch-options``, ``patch-binary`` and ``patch-revision`` options.
  (options ``EGGNAME-*`` are also supported as well).

In order to have as canonical as possible paths, chomp ../ from filenames and
recalculate base.

[ci skip]

Nicer version constraint logging + better requirement conflict info logging

The tests fail to run due to the deprecation warnings, so I stripped 3.2 out of travis.

Added 3.5 instead as that's the most modern version.

"dist" can be a PathMetaData instance, req.key is nicer. The latter has a .lower()...

Before you'd get a simple output like:

    Installing django.
    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

... which would mean you'd have to grep in all your requirements'
sub-requirements which package actually requires the offending "django>=1.7"

With this change you'll get a much more helpful output right before the error:

    Installing django.
    version and requirements information containing django:
      [versions] constraint on django: 1.6.6
      Base installation request: 'sso', 'djangorecipe'
      Requirement of djangorecipe==1.10: Django
      Requirement of djangorecipe==1.10: zc.recipe.egg
      Requirement of djangorecipe==1.10: zc.buildout
      Requirement of sso: django-nose
      Requirement of sso: django-mama-cas
      Requirement of sso: django-debug-toolbar
      Requirement of sso: django-auth-ldap
      Requirement of sso: Django<1.7,>=1.4.2
      Requirement of lizard-auth-server: django-nose
      Requirement of lizard-auth-server: django-extensions
      Requirement of lizard-auth-server: Django<1.7,>=1.6
      Requirement of django-nose: Django>=1.2
      Requirement of django-nose: nose>=1.2.1
      Requirement of django-mama-cas: requests==1.1.0
      Requirement of django-debug-toolbar: sqlparse
      Requirement of django-debug-toolbar: Django>=1.7
      Requirement of django-auth-ldap: python-ldap>=2.0
      Requirement of django-auth-ldap: django>=1.1
      Requirement of translations: Django>=1.4
      Requirement of django-extensions: six>=1.2
    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

This makes it much easier to spot the cause (in this case
django-debug-toolbar).

There *are* some unrelated packages in here because I'm doing a textual
comparison. The advantage is that it is very robust. And extracting the right
package name from requirements without messing things up is harder to get
right and takes more code.

- Adjusted the now-clearer error.
- Removed error log message as that's now in the actual error message

Previously:

    The constraint, 1.6.6, is not consistent with the requirement, 'Django>=1.7'.
    While:
      Updating django.
    Error: Bad constraint 1.6.6 Django>=1.7

Now:

    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

The original message said "bad constraint". No, the constraint is not
necessarily bad. It only conflicts with some other package's requirement.

The new message tells you that "constraint" means "your own [versions]
list".

[ci skip]

[ci skip]

Fix #279 on windows

[ci skip]

[ci skip]

Same as #277, but with test and changelog entry

The base dir ("develop = .") should be relativized, too, but currently isn't.
This test proves that it doesn't work (it will be fixed by #277)

For example when you use the develop option like:

  [buildout]
  develop= .

Fixed winbot test. Didn't think about -script and .exe

See http://winbot.zope.org/builders/zc_buildout_dev%20py_270_win64%20master/builds/1149/steps/test/logs/stdio

[ci skip]

[ci skip]