Introduce an [editorconfig] configuration file to tell developer editors that we want an empty line at end of file.

After making softwares and component uses a buildout.hash.cfg file, run [eclint] fix to apply the style.

eclint is also added in the commit hooks (that one can install with `npm install` from the root of this repository)

[editorconfig]: https://editorconfig.org/
[eclint]: https://github.com/jedmao/eclint

See merge request nexedi/slapos!757

It seems `eclint fix folder/file` sometimes dos not work, but `eclint
fix folder/` worked.

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

So that we all edit files in a consistent style

Sometimes, gitlab and qemu are reported by software release tests to link against libcap-ng and libzma from system. This happens when the development packages are installed on the system.

Approach here is to build with slapos version of the libraries.

See merge request nexedi/slapos!789

Using an script to set the environment is easier to use, but the main
reason is that if we want to be able to use shared part from outer
slapos (like when using in theia or slaprunner), the working directory
for test must be contained in the instance directory of the outer
slapos, so that when we run slapos node prune in the outer slapos this
command can see that shared parts are used.

This was using zlib and lzma from system if they are available, so we
tell bundler to use the slapos version.

We have to use both in --with-cflags for nokogiri itself and as CFLAGS
environ for when nokogiri build its included libxml2

don't let configure autodetect and build something different depending
on the presence of this library on the host system

Explicitly build with libcap-ng instead of depending on presence of the
development library on the host.

Also fix the way of disabling tinfo, there was warning at the end of
configure saying this option is not used

Backend logs are exposed as usual access and error logs.

By using rsyslogd templates and regex filtering, the rsyslogd reacts itself
and creates needed files per each slave which accesses it. Thanks to this, it's
configuration is static from point of view of SlapOS profiles, and can be
generated once.

As the rsyslogd configuration became fully special to backend-haproxy, the
rsyslogd template filename and its references has been correctly renamed.

Logs are critical for caddy-frontend, so let's configure rotate-num locally,
as changes in the stack can come unattended, and can result with loosing logs.

We moved out from local logrotate configuration long time ago, it was just
leftover.

haproxy by itself provides good information, so there is no need to add
information from rsyslogd itself.

The logrotate folder also serves as an publication folder for logs, so be sure
that logs are linked there.

While building haproxy on one machine, and using it on another, the CPU
optimisations can lead to haproxy not working at all on other CPUs.

In context of SlapOS packages are distributed in binary form, so haproxy
binary has to support all CPUs.