get is used by __getitem__, but also by other callers as it is public
method. So deserialize values if needed on each access by get, and
remove now needless deserialization in __getitem__

As Options.get is used internally, add Options._get without
deserialisation and use it in places, which expect clean result, and
adapt Options.get to be simple wrapper with deserialization without
using decoration with functools.

/reviewed-on nexedi/slapos.buildout!10

so that it can be imported even when buildout instance is not initialised.

Now specified patches are automatically applied on required eggs as well.

Fixup to commit "Add referred parts' hash strings in __buildout_signature__,
that invokes rebuild of a part when one of its (recursive) dependencies are
modified."

  While invoke setup.py certain eggs (like scikit-learn) launch
  cetain custom builds (for cython) using subprocess and sys.executable.

  This commit aims to preserve the sys.path over the runs, even if an
  egg is using subprocess with the same python to build a component of
  the egg.

   This commit is part of fixup the "Add setup-eggs option in zc.recipe.egg:develop."

This change fixes bug introduced in https://lab.nexedi.cn/nexedi/slapos.buildout/commit/aba00feb5cc694be6da433d936e29c94f9ae0416 for develop.

As _install_setup_eggs is part of Base class, some code
from Custom.__init__ had to be moved to Base.__init__ as those were
required by _install_setup_eggs implementation as self.link, options['_e'],
self.newest and so on.

Without this change zc.recipe.egg:develop fail to process.

Also, updating a part does not put it anymore at the end of the list of
installed parts, that was making .installed.cfg too big.

Useful when recipes generate non-string values to be reused by other
recipes.

Add referred parts' hash strings in __buildout_signature__, that invokes rebuild of a part when one of its (recursive) dependencies are modified.

Also remove duplicates and sort entries in __buildout_signature__.

In SlapOS, bootstrap is called each time software release is invoked and
we do not want to delete develop-eggs directory.

This reverts commit 55d76b34.

--setuptools-version and --buildout-version options in bootstrap script still have the priority.

https://bugs.launchpad.net/zc.buildout/+bug/144228

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).