Also drop now needless etc/promise directory.

As possible cover promises in tests.

Assert that machine running tests is good enough for KVM tests.

monitor-boostrap.pid existence is unpredictible.

In test nodes we put the software_root folder out of the webrunner so we
can keep it for the following tests. Except that the shared folder has
been introduced by default recently, and it is still inside the webrunner.

Thus, between 2 tests the webrunner is deleted, so the shared parts are too,
but not the SR folder (which is marked as completed). Then in the successive tests
the software release fails to build, or the insances fail to isntanciate.

/reviewed-on !654

It has been moved to component/rdiff-backup, but it was been forgotten to clean it here

runTestSuite.in uses _update_hash_filename_ compatbility to avoid clash with
section's filename key.

As software.cfg is extended by other software releases rename the template
part to template-neo in order to avoid clash of sections.

instance.cfg md5sum has been omitted.

_update_hash_filename_ key is used to avoid clash with recipe.

hexagonit.recipe.download is replaced with slapos.recipe.build:download in
order to have the same approach everywhere and so _update_hash_filename_ key is
used to avoid collision with section:filename.

Use _update_hash_filename_ to avoid filename clash with recipes.

_update_hash_filename_ is used to avoid conflict of section:filename key with
hexagonit.recipe.download

A lot recipes treats filename key as something special, so for them support
additional key _update_hash_filename_, in order to avoid such clash.

In 95c05120, a published parameter "ssh-url" was added
to the webrunner, clashing with the existing "ssh-url" parameter used by the resilient
stack (which is extended by webrunner).
As the new "ssh-url" is public and read by customers, it doesn't make sense to rename
it to something more slaprunner-ished, more especially it already existis "ssh-command",
so if a second parameter was named "runner-ssh-url" it wouldn't make sense to the user...

This change had to be propagated to all the software releases extending the resilient stack.

Finally, I think that stacks should use namespaces to avoid conflicts with the software
releases extending them. Currently, we are doing the opposite and are using namespaces
for software release to avoid conflicting with their stack : for exemple, in stack/resilient
we have a section [sshd-raw-server] and in the software/slaprunner we have [runner-sshd-raw-server].
This situation will create clashes when one software release extends 2 stacks, as nothing
guarantees that 2 stacks have no conflicting section name, config file path, ...