Let 2023.06 modulefile redirect RISC-V clients to riscv.eessi.io, add symlink for 20240402 version

[bedroge]

This allows RISC-V clients (and, in particular, the build bot) to use the same modulefile as we use for software.eessi.io. By adding a symlink 20240402.lua -> 2023.06.lua we can reuse the exact same modulefile. Note that I haven't added the symlink to install_scripts.sh, which ensures that it won't be deployed to any repo (it would be confusing to have this in software.eessi.io, and we don't actually need it in riscv.eessi.io either, as long as it's available in the git repo; the bot sources the file from the git repo). The only slightly confusing thing is that the RISC-V repo will deploy the 2023.06.lua modulefile, so users from that repo will only see EESSI/2023.06. But I'm not really sure how to prevent that, except by adding a bunch of specific if statements to install_scripts.sh.

Instead of this approach we could also modify the EESSI-install-software.sh script and do something like this:

if [[ ${EESSI_CVMFS_REPO} == "/cvmfs/riscv.eessi.io" ]]; then
    # For the RISC-V repository we don't have a module file, so stick to the bash init script
    source $TOPDIR/init/bash
else
    module use $TOPDIR/init/modules
    module load EESSI/$EESSI_VERSION
fi

But I liked the solution with the modulefile a bit more.

[riscv-eessi-io-bot]

Instance eessi-bot-riscv is configured to build for:

• architectures: riscv64/generic
• repositories: riscv.eessi.io-20240402

[eessi-bot]

Instance eessi-bot-mc-aws is configured to build for:

• architectures: x86_64/generic, x86_64/intel/haswell, x86_64/intel/skylake_avx512, x86_64/amd/zen2, x86_64/amd/zen3, aarch64/generic, aarch64/neoverse_n1, aarch64/neoverse_v1
• repositories: eessi.io-2023.06-compat, eessi-hpc.org-2023.06-software, eessi-hpc.org-2023.06-compat, eessi.io-2023.06-software

[eessi-bot]

Instance eessi-bot-mc-azure is configured to build for:

• architectures: x86_64/amd/zen4
• repositories: eessi.io-2023.06-compat, eessi.io-2023.06-software

[bedroge]

Successful build with the RISC-V bot using this approach in #803 (comment).

The latter still had a hardcoded eessi_version = "20240402", it's now doing another one with the more flexible eessi_version = os.getenv("EESSI_VERSION_OVERRIDE") or "20240402":
#803 (comment)
(from the logs I can already see that the build was successful, it's now running the test step)