We can set a specific port-base to use for monitor instance. We can also activate
or desactivate monitor by using parameter "monitor": true in zope or mariadb parameters.

Conflicts:
	stack/erp5/buildout.cfg

Conflicts:
	software/slapos-master/instance-erp5.cfg.in
	software/slapos-master/software.cfg
	stack/erp5/buildout.cfg
	stack/erp5/instance.cfg.in

Conflicts:
	stack/erp5/buildout.cfg

Sorry everyone for this mistake.

Conflicts:
	software/neoppod/software.cfg
	stack/erp5/buildout.cfg
	stack/erp5/instance-erp5-cluster.cfg.in
	stack/erp5/instance-erp5-single.cfg.in
	stack/erp5/instance-zope.cfg.in

This reverts commit f2e57a03.

In order not to conflict with a future integration of NEO in ERP5:
- the input schema has a new parameter for external storages.
- zodb-software-type & zodb is used only for internal storages
  and only ZEO is supported.

NEO logging is also enabled for clients.

Contrary to ERP5, there's no mysql-update service:
- this simplifies the SR
- after reading the MySQL documentation, the automatic use of mysql_upgrade
  is quite frightening:
  « You should always back up your current MySQL installation before performing
  an upgrade. »
  « After running mysql_upgrade, stop the server and restart it so that any
  changes made to the system tables take effect. » (which is currently not done
  by the recipe)
- the future of NEO is an embedded DB like libmysqld

New 'slapos-kill' from slapos.toolbox is used instead of 'killpidfromfile'
This is required for NEO which does not write any pid file.

The inline recipe for ERP5 has been improved and converted into recipe,
which is reused for NEO.

Templates are instanciated only if they're used, so no need anymore to
wrap them with:

  {% if slap_software_type == software_type -%}
  ...
  {% endif %}

slapos.core 1.3.X introduces regressions.

No need to expose this slapproxy to the outside.