Refactor action

[viperML]

The following have been changed:

• Reworked variable names to ones that make more sense.
• environment must be provided by the user.
• Pushing is delayed after the build is done.
• Mirrors are sane config defaults auto-applied.

Marking as draft because I want to figure out:

• Declaring extra Spack repos to add (spack.numpex)
• Automatically loading Spack with shell support (spack env activate fails)

[viperML]

The Spack environment should be automatically loaded now

[viperML]

@prudhomm the installation of Spack itself has been pulled out of the action, as this composes better. Otherwise, it is hard to have any extra actions to configure the Spack installation step.

This is inspire by similar actions in the Nix ecosystem, see https://github.com/DeterminateSystems/magic-nix-cache-action#usage

[viperML]

As github actions only take strings as input, it is easier to express the possibility of multiple repos being added (spack.numpex etc) by having action steps.

I have created a very simple action to add a repo, this should be moved to the numpex org aswell (maybe before?)

https://github.com/viperML/spack-repo-action

[viperML]

Note that from spack 1.x it will not be necessary to add the spack.numpex repo, as it will be possible to define the dependencies and their commits in an environment's spack.yaml.

[prudhomm]

@viperML it will break a few repos, if we merge, I need to make a version first to have the time to update these repos

[viperML]

it will break a few repos, if we merge

Then we should start using versions so that consumers of the action can pin an API-compatible version e.g. v1, v2, etc.

In any case, I wrote this action a month ago. In the meantime Spack has been undergoing changes related to the v1 release, including the usage of the spack-packages repository. This PR is probably already obsolete now or as soon as v1 is released as stable.

[prudhomm]

We are already at v1, so it will be bumped up to v2. But I have to check the repos that they are at v1 for now