and clean up some duplicate version pins

Change python2 softwares to use python2 explicitly and python3
softwares to use the default, but leave a few softwares (html5as,
html5as-base, fluent-bit, packer, seleniumrunner) using the default
python, as they were using python2 not because they only support python2
but because they don't have strong dependency to the python version
being used.

done with:

     npm install
     git ls-files | grep -v '\/unstable\/' | xargs ./node_modules/.bin/eclint fix
     git ls-files | grep buildout.hash.cfg | xargs ./update-hash

  Creating this file and updating the slapos.cfg configuration
  is possible to call slapos node format from the partition in the
  same way you would do in a computer.

TODO: There are still direct references to specific version of Python in:
  - slapos component
  - bazel templates
  - nextcloud & theia SR

When we have a section to generate a python interpreter with eggs built
in, don't name this `extra-eggs` because the meaning is not clear.

This section installs slapos.toolbox eggs with dependencies and install
scripts

Despite the name, this section was inherited from monitor, but now that
we fixed monitor to prefix the sections, this section is no longer
extended from monitor, but defined in softwares

This section installs a slapos command with network cache enabled, for
softwares using an embedded slapos.

As we have runners with a section deployed using
collective.recipe.shelloutput, if collective.recipe.shelloutput isn't in
the SR folder anymore thisi section can't be uninstalled (as the
uninstall method is defined in the egg).

The output of buildout for this error was :

While:
  Installing.
  Uninstalling runner-sshkeys-publickey-fingerprint-shelloutput.
  Installing recipe collective.recipe.shelloutput.
  Getting distribution for 'collective.recipe.shelloutput'.
Error: We don't have a distribution for collective.recipe.shelloutput
and can't install one in offline (no-install) mode.
While:
  Installing switch_softwaretype.

The cause was f936ea2c

The fixes a conflict with 'runner-exporter' due bugs in cns.recipe.symlink

Anyway, a much better idea would be to add ~/software_release/bin to PATH.

collective.recipe.shelloutput does not work well with Python 3: it
outputs values as bytes, which are printed in the format "!py!b'XXX'".

The new "init" option is used as a replacement.

This reverts commit 2cc61477.

Now we now, without "futures" egg, gunicorn refuses to start:

    Error: class uri 'gunicorn.workers.gthread.ThreadWorker' invalid or not found:

    [Traceback (most recent call last):
      File "/srv/slapgrid/slappart14/srv/testnode/cqc/inst/test0-0/tmp/soft/8c22f5a21e7f016f38916f098ab2339b/eggs/gunicorn-19.7.1-py2.7.egg/gunicorn/util.py", line 134, in load_class
	mod = import_module('.'.join(components))
      File "/srv/slapgrid/slappart14/srv/testnode/cqc/inst/test0-0/tmp/shared/python2.7/8d8826883d34c5a7ec7a5b8c187d89c9/lib/python2.7/importlib/__init__.py", line 37, in import_module
	__import__(name)
      File "/srv/slapgrid/slappart14/srv/testnode/cqc/inst/test0-0/tmp/soft/8c22f5a21e7f016f38916f098ab2339b/eggs/gunicorn-19.7.1-py2.7.egg/gunicorn/workers/gthread.py", line 37, in <module>
	""")
    RuntimeError:
	You need to install the 'futures' package to use this worker with this
	Python version.

Yet another non-obvious change that was committed without explanation.
Let's revert and see what breaks...

The OS may not have Python (slapos-node package does not depend
on any version of Python). Another possible issue was found on Suse:

  make[3]: Entering directory '.../parts/glib__compile__/glib-2.56.4/gio'
    GEN      gdbus-daemon-generated.c
  Traceback (most recent call last):
    File "./gdbus-2.0/codegen/gdbus-codegen.in", line 53, in <module>
      from codegen import codegen_main
    File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/codegen_main.py", line 30, in <module>
      from . import parser
    File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/parser.py", line 23, in <module>
      import xml.parsers.expat
  ImportError: No module named xml.parsers.expat

If slaprunner itself was installed on a slapos which had shared parts
enabled, these shared parts will also be used while installing softwares
inside the slaprunner.

Because ${buildout:shared-part-list} is a multi line property, it was
not possible to generate .cfg files (which needs special handling of
multi-line strings) directly from software buildout (where jinja
templates are not yet available), so we use a trick of generating a
plain text file in software and parsing it during instance.

Instead of having to copy and paste the "ssh command", having a
clickable link is more user friendly. This integrates seamlessly with
ChromeOS secure shell app (eventhough the app does not do anything with
fingerprint as per version 0.19)

They are dependencies of slapos.toolbox and we already agreed to put slapos.toolbox version in a shared file.

/cc @jerome @jm

/reviewed-on nexedi/slapos!502

/reviewed-on nexedi/slapos!427

  As this is used by the tests.