Package installation/upgrade tests

Time consuming, as 10.000 lines of code need to be moved to New Buildbot

Expectations outlined by @elenst. If they turn out to be wrong, @elenst would like to hear what exactly is different. The terminology is from the old buildbot.
pre-conditions (not related to the scripts themselves):

• make KVM machines work, create a couple of VMs – e.g. one with deb-based linux, one with rpm-based – with a default installation, as clean as possible, no development environment and alike;
• create builders which will launch these machines and copy into them packages built elsewhere, currently in docker;
  moving the scripts:
• copy-paste from the old buildbot config to a separate file php functions which define installation and upgrade tests, e.g. getRpmInstallStep and such, each of which is basically one gigantic shell step (generic Shell or more likely the step Test which is pretty much the same).
  There are probably half a dozen of them, or so;
• rename the steps and concepts if necessary (it's one few-line block per function);
• search for properties like %( and see if they match what the new buildbot has, or need to be renamed, or need to be created (some were defined in the old buildbot, you can see how);
• search for php injections like """ + ... + """ and do the same;
• move the edited functions to the new config;
• make the builders created in pre-conditions call the steps;
• take the same approach for remaining one or two steps (I think in Debian factory, the legacy ones) which are not defined as php functions but directly as shell steps in the factory;
  debugging:
• run, get it fail, fix, repeat.

Additional things:

• Upgrade tests only needed from previous main version to the next (like 10.4 -> 10.5 but not 10.3 -> 10.5)
• In old buildbot for RPM's we try to upgrade from the latest RPM released for the previous MariaDB version to the built one. For Debian we use a random previous package. In new buildbot we should use the latest released package in all cases.
• We also need to do minor upgrade tests from previous released version from mariadb.org, for example MariaDB 10.5.1 -> MariaDB 10.5.2. This doesn't have to be done for a 0 version, like MariaDB 10.6.0