Let ingest_tarball.sh support custom installation prefixes

[Neves-P]

With this PR we are in the last (?) steps to generalize support for custom installation prefixes, following from EESSI/software-layer-scripts#239 and EESSI/software-layer-scripts#295

This is still a draft, as the verions subpath argument must still be obtained from the tarball metadata. This is currently not encoded anywhere we can easily gather at the ingestion stage.

• Added optional third argument for the repository-relative versions subpath:

  ingest-tarball.sh <repository> <tarball> [versions subpath]

• Defaults to versions, preserving standard repository behavior.
• Removed the dev.eessi.io-specific filename inference.
• Added validation preventing absolute paths and ./.. path components.
• Ensured Lmod searches the custom subpath in the target repository while still using software.eessi.io/versions when falling back.

[boegel]

@Neves-P Can you clarify why you're closing this?

[Neves-P]

@boegel sorry about that! That was unintentional, I accidentally deleted the wrong branch on my fork!

[Neves-P]

I don't get why scripts/automatic-cvmfs-named-snapshot/automatic-cvmfs-named-snapshot.sh is in the list of changed files because it isn't in any of the commits... 🤔

[Neves-P]

Now I am indeed closing this one in favor of #282. Both approaches work and are backwards compatible with the existing workflow, so that merging them won't break anything. @bedroge's approach, however, already accommodates custom installation prefixes without requiring that the installation subdir variable is passed all the way through the software layer, and bot build and ingestion code.

Let's go with #282 instead, otherwise we delay this for longer. However, the aim of leveraging a custom installation prefix for dev.eessi.io is still good and we need to stop treating dev.eessi.io as a special case whenever it can actually fit in the normal workflow. Otherwise we risk keeping two diverging build and ingestion workflows for a long time which will only become more of a hassle to maintain. For that, see -> #284