See #85 (review)

Background

We have a hole in our testing infrastructure, in which changes to spack-config aren't tested.

We can use the build-ci infrastructure to test building the packages in access-spack-packages, in a similar way to the custom ci in that repository, only varying the version of spack-config.

Implementation Plan

• Look at https://github.com/ACCESS-NRI/access-spack-packages/blob/main/.github/workflows/ci.yml for inspiration. Matrix building would be done based on what (symlinks to) files have changed (eg., modifications to v0.22, or common, or common-api-v2).
• Clone the .github/build-ci/manifests from the default branch of access-spack-packages, and potentially use that as the source of package definitions - it would be annoying to have to create even more manifests that would be functionally the same as the ones in access-spack-packages. Maybe in the future manifests defined in the spack-config repo could override the ones in access-spack-packages, but we'll see if that is needed.