Restructure and improve version-includes

version-includes are now called version-sets and unlike before where we had a single set of versions that we could build for, we now support having multiple sets. This allows users to create their own version set, which is encouraged so that they can build NSO in Docker and surrounding repositories for the versions of NSOs that they care about.

Given how we now support continuous mirroring while at the same time allowing modifications to files, we must now keep in mind that the type of modifications we encourage should come with a low likelihood of merge conflicts. This change aims to drastically reduce the risk for merge conflicts. Previously, the version-includes files essentially contained what is the list of supported NSO releases. This list changes as soon as a new version is released or an old one goes out of support - it's quite a lot of changes. If someone wanted to write their own list of NSO versions and tried to do this by overwriting /version-includes/versions.json + regenerating all the surrounding files, that would be a recipe for constant merge conflicts as the next update to the list of versions would mean a conflict. What we now offer is the possibility of creating a completely separate set of versions - you get your own version set, which you control. The old /version-includes/* files now live in /version-set/supported-nso/ to reflect that it is actually a list of supported NSO versions. Users never have to touch that list. Instead a user creates their own version set, for example /version-set/foobar/ and the risk for collisions is thus near zero. In the main .gitlab-ci.yml file, the right version-set has to be included. It's a single line of change and so I predict there is a very low risk of merge conflicts for that change too.

Closes #107 (closed)