Simplify the extensions on testSlapOSConfigurator to the expected bt5 and modules list

   This allow us to translate and re-run the tests with real notification messages.

   It ensure that selected payment is from the proper user.

  Also, keep paths specific to not conflict with extra business templates. We don't
  want a polluted list after the installation of extra bt5 on development or
  project specific environments.

   This allow introduce minor custom changes on project specific context w/o re-implement the whole test.

   This makes easy to overwrite and custom the list on sub-level projects

    Reported-by: Romain

Instead of letting slapos commands start supervisord in daemon mode, run it
as a program from standalone supervisord daemon.

The $INSTANCE/etc/supervisord.conf will be created by `slapos node instance`
the first time user runs it, until this, the service will restart in a loop,
complaining that config file is not found.

Also review stop to expose timeout argument and use a longer timeout by
default (and cleanup some unused imports).

I guess this code was using python -S to try to be independant from anything
that can happen in site.py, but that's not needed when running on testnode.

pygolang.pymain does not support -S and we are moving tests environments to
use pygolang.pymain, so let's remove this if we don't need it.

- also write pid file to prevent race condition
 - check user is root

See merge request nexedi/slapos.core!267

   Defined on the Constraint

   Include more verbose to the scripts to make debug easier.

See merge request nexedi/slapos.core!268

When comparing OS to see if they match for binary cache, we only compare
the lower case distribution name because sometimes "Debian' is
capitalized and sometimes not.

   It helps multi-account users to identify better where the notifications are coming from.

    On  Regularisation Requests context.

     We don't want extra movements been created, so this changes overwrites this behaviour of erp5.

   Invoice display's if user's organisation name (if set, in addition to his) and organisation address (if set replaces his), so his company can be invoiced rather them user.

I had a Theia instance where I installed buildout with `pip install -e --user /path/to/checkout` and later deleted that `/path/to/checkout` and this made it impossible to run instance buildout, failing with import error when importing zc.buildout  in buildout script.

This is because python load user site packages by default. I believe we don't want this, a broken user site package should not prevent slapos from running buildout.

These changes are about running buildout with `PYTHONNOUSERSITE` set, so that python ignores user site packages when running buildout.

references: 

 * https://docs.python.org/3/using/cmdline.html#envvar-PYTHONNOUSERSITE
 * https://docs.python.org/3/library/site.html#site.ENABLE_USER_SITE

See merge request nexedi/slapos.core!266

When config specifies root_check=true, check that user is root instead
of probably failing with error messages because some permissions would
be refused.

slapos node prune already detected the case where software was running
and refused to run while software was runnning, to prevent a case where
software writes files and prune removes them because they are not yet
referenced, but nothing prevented the other way around: slapos node
software should not start while slapos node prune is deleting files. To
prevent this, make slapos node prune actually use software pid file,
then software will refuse to start while prune is running.

When PYTHONNOUSERSITE environemnt variable is set, python does not load user
site.
User site packages may contain a different version of buildout, which would
be selected when slapos runs buildout, causing unexpected behaviours.

Some buildout profiles are expecting this.

 - Use dict.items() to iterate on dict, instead of dict.keys() then dict[key]
 - don't use six.iterkeys(), this dict is small, so we don't need iterkeys()
   on python2 and can already write python3 version
 - don't % string when invoking logger, logging framework do it for us and do
   it only if message will be logged.

    For historical reason some aggregated packing lists could be merged (due a bug). This changes introduced backward compatibiltiy with those cases, rather them require a data migration.