feat: Add devcontainer feature and update setup script for CVMFS

[wdconinc]

This PR adds a Devcontainer Feature layer configuration reusing the GitHub Action scripts.

This allows downstream users that already base their GitHub Actions on for example LCG releases to now provided online Codespaces environments that can access the LCG releases. This, in turn, allows the GitHub Copilot interactive experience inside the browser to replicate what is already possible on local VS Code systems or in GitHub Actions.

This started off as #45, but in order to streamline the setup-cvmfs.sh parts, we can't place the devcontainer-feature.json inside src/cvmfs/ because only the subtree starting where devcontainer-feature.json is located is accessible inside the feature build (well, in the integration in the surrounding devcontainer build).

Not all variables in action.yml are ported to devcontainer-feature.json, since I have no way of keeping them synchronized.

Devcontainers don't run autofs (well, they don't run systemd), so we have to mount specified repositories explicitly. (We could also start autofs with service autofs start, but that's a bit more obscure than mounting repositories.)

Publishing of the Devcontainer Feature to ghcr.io as an OCI layer will need a PAT to be added as repository secret with write:packages permissions, I think.

[wdconinc]

There is not really a way to build the feature locally, build a dev container locally, and test it locally (which is weird; it's just docker stuff with a wrapper).

[wdconinc]

@vvolkl What would be the process to get the GitHub Actions release create action to have permissions (via token) to push to ghcr.io/cvmfs-contrib/github-action-cvmfs? Feel free to reach out on mattermost (wdeconin now since I got my group registered with CERN).

[ocaisa]

@bedroge may have some advice there, we do that for the EESSI client and build containers.

[bedroge]

@bedroge may have some advice there, we do that for the EESSI client and build containers.

I'm not familiar with devcontainer, but we just use the docker/login-action (https://github.com/docker/login-action?tab=readme-ov-file#github-container-registry) to authenticate to GHCR, and then docker/build-push-action to build and push the image to the registry.
See for instance https://github.com/EESSI/compatibility-layer/blob/main/.github/workflows/build-and-publish-bootstrap-container.yml for a quite small example, also note that the workflow needs packages: write permissions.