Clean up dev.eessi.io-specific code (assume it's doing a site installation) and improve tarball creation step for site installations

[bedroge]

This improves the workflow, in particular the tarball creation step, for site installations that are done in a subdir of a CVMFS repo, e.g. with $EESSI_SITE_SOFTWARE_PREFIX=/cvmfs/my.repo.tld/eessi. Though builds with such a prefix already work fine, the tarball step is unable to find the installations.

I've made the solution as generic as possible by introducing a variable EESSI_VERSIONS_SUBPATH that defines the relative path (from the root of the CVMFS repo) to the versions subdir. For standard builds (software.eessi.io) it's just set to versions, but for site installations it would become e.g. eessi/versions by stripping the CVMFS repository from the path and appending versions.

This is also useful for dev.eessi.io, as these builds also already go into a project directory. The workflow introduced here is a first step towards removing all the if statements that check for EESSI_DEV_PROJECT or dev.eessi.io: ultimately, the dev repo can just do a site installation by setting EESSI_SITE_SOFTWARE_PREFIX=/cvmfs/dev.eessi.io/$EESSI_DEV_PROJECT, and all the logic of site installations would apply.

[bedroge]

I've also removed the sort of hack where we appended EESSI_DEV_PROJECT to EESSI_CVMFS_REPO_OVERRIDE (it would become e.g. /cvmfs/dev.eessi.io/riscv) to make the scripts aware of the additional subdir in the path. The new $EESSI_VERSIONS_SUBPATH now takes care of this, so we can point EESSI_CVMFS_REPO_OVERRIDE to the root of the repo again, making things cleaner.

This actually fixes another issue: EESSI-install-software.sh would run basename on EESSI_CVMFS_REPO_OVERRIDE to check if the easystack files were in a directory named after the repository. For /cvmfs/dev.eessi.io/riscv that would mean though that they had to be in a directory named riscv, which is not consistent behavior. With the changes here, it will expect them to be in a directory dev.eessi.io instead of e.g. riscv or espresso.

[bedroge]

Changing dev.eessi.io builds to site installations is probably a small change now (mostly a matter of setting EESSI_SITE_SOFTWARE_PREFIX=/cvmfs/dev.eessi.io/$EESSI_DEV_PROJECT in the dev build script, and removing some checks in the workflows), so maybe I'll go ahead and do that in this PR as well.

[bedroge]

Okay, with https://github.com/EESSI/dev.eessi.io-scripts/pull/3 and this PR, dev.eessi.io builds should now make use of the site installation functionality. A lot of code has been cleaned up by removing the dev.eessi.io-specific cases, all of it should be handled by the code that was recently introduced for site installations. The main thing that I did have to add was the one line of code that removes any version suffix from the EESSI version, as that was done in the dev bot's build script (see https://github.com/EESSI/dev.eessi.io-scripts/pull/3). This is relevant for dev.eessi.io/riscv, which has a version like 2025.06-001, and that needs to be converted to 2025.06 to get the correct compat layer path.

[bedroge]

I'll try to run a bunch of test builds with the standard software.eessi.io bot, a dev bot, and a local site bot to test the different scenarios.

[bedroge]

Note: when this gets merged, we should update https://www.eessi.io/docs/adding_software/adding_development_software/. It's already outdated, but this PR also changes the directory structure for easystack files (again).