Rework perl installation to install each package in a separate directory.

Each package install a `perl` interpreter for each package, which is implemented a shell wrapper setting `$PERL5LIB` with the path of this package and its dependencies.

To install a perl package, use `perl-CPAN-package` macro, like in this example for a fictional `XXX::YYY` package:

```
[perl-XXX-YYY]
<= perl-CPAN-package
module = XXX/XXX-YYY
version = 1.2.3
md5sum = ab68b329da9893e34099c7d8ad5cb9c940cd123
```

This will download package from https://www.cpan.org/modules/by-module/XXX/XXX-YYY-1.2.3.tar.gz and install using the usual `perl Makefile.PL && make && make install` sequence.

To install package with dependencies, use the `inc=` argument, like in this example for  another fictional package `XXX::ZZZ` package that would depend on `XXX::YYY` and `XXX::ABC` :

```
[perl-XXX-ZZZ]
<= perl-CPAN-package
module = XXX/XXX-ZZZ
version = 1.2.3
md5sum = 401b30e3b8b5d629635a5c613cdb7919

inc = ${perl-XXX-YYY:site_perl}:${perl-XXX-ABC:site_perl}
```

The full list of options is described in the [macro](https://lab.nexedi.com/nexedi/slapos/blob/a5bec95c/component/perl/buildout.cfg#L31-65).


That macro creates an interpreter for each package, but sometimes we need to create an interpreter with multiple packages. The `perl-wrapper` macro is available for this. It also accepts a `inc=` argument in the same format. Because this wrapper is implemented using `-I` argument, it is also suitable for scrips running in perl [taint mode](https://perldoc.perl.org/perlsec.html#Taint-mode-and-%40INC), like the w3-validator we are using.

All perl components and perl usages have been updated to this new infrastructure.

Some (apparently) unmaintained components were using an obsolete `slapos.recipe.build:cpan` recipe. They were used only in mioga2 from unstable, so I moved them inline in mioga2 software.

/reviewed-on nexedi/slapos!341

( mostly because old version is no longer on CPAN )

( mostly because old version is no longer on CPAN )

We stop using slapos.recipe.build:cpan , but these unstable components are
not ready and not being actively maintained, so move them inline in
mioga software, which was the only user of these components.

When the work on this is resumed, we should switch to perl-CPAN-package
here as well.

Generate a wrapper with all dependencies available

${perl:location} is now a perl without any package, components using
perl with one specific package must switch to using the perl with the
dependent CPAN packages installed.

Installing everything in site_perl is not the "buildout way" and is
incompatible with the upcoming shared slapos.recipe.cmmi

  This version contains optimisation for restore (and a bit for backup), specially in case of large sets of unmodified files.

this parameter is used for external service like saucelab to access test url

Drop support for Go 1.8; Add support for Go 1.10 and make it the
default.

It comes a bit late because previously we were hitting
https://golang.org/issues/24285, and so have beeing waiting for
nexedi/slapos.core!42 to be
deployed there on slapos nodes everywhere.

As of 9 Aug 2018 it seems that deployment has been completed.

/reviewed-by @alain.takoudjou, @rafael.
/reviewed-on nexedi/slapos!372

/reviewed-on nexedi/slapos!368

the recipe slapos.cookbook:generate.password will install the password only after the [request-xx] was called for the first time. Then the second run of buildout the password can change as it was not stored yet. We use publish-early to make it persistent on master and avoid inconsistency between published password and stored one.

/reviewed-on nexedi/slapos!370

This option is not advertised and it is not needed at all in Caddy
configuration.

As monitor stack uses values directly from buildout convert them to buildout
safe values, otherwise the the magic !py! is not stripped.

Also add a test proving that monitor with default values is going to be
correctly configured.

It sometimes results with returning passwords with newlines, thus they have
to be trimmed.

Features:

 * jinja2 is used to generate instance templates
 * downloads are done the same way for all resources
 * create with shared content for all instance profiles
 * fill in instance-common with shared sections
 * render templates late in order to ease its extenension and development
 * drop not needd duplicated section
 * drop slap-parameter in frontend and replicate template
 * simplify monitor configuration
 * move instance-parameter to instance file
   Thanks to this only one and topmost profile is reponsible for parsing and
   passing through the information which comes from the network