GH Actions: automate release tarball creation (WIP)

[fingolfin]

This is based on work by @FriedrichRober and @ssiccha . Still needs some refinement.

For now the CI job added here will only run in my repo, so you can see the state here: https://github.com/fingolfin/gap/actions/

For a run with a tag, see here https://github.com/fingolfin/gap/actions/runs/594082465 and check the list of releases for the result: https://github.com/fingolfin/gap/releases -- so this immediately shows a bug: the tag which triggered the CI job was named v6.7.8, but the script ended up creating and populating a v4.12dev tag. Reason: the v6.7.8 tag, created via the GitHub web interface, is not an annotated tag...

Some possible TODOs (all up for debate, though):

• if the tag triggering the CI action does not match the version in GAP, perhaps abort?
  • to facilitate this, the tag name detected by the action could be passed as an (optional!) argument to the make_github_release.py script
• the make_github_release.py should perhaps only accept tags matching the pattern vX.Y.Z with X,Y,Z all numbers, and thus reject v4.12dev (
• the artifact uploading right now uploads all .zip and .tar.gz as a single artifact... so as a single file... that's not at all what we want. we can resolve this by duplicating the actions/upload-artifact@v2 multiple times (using some regex to avoid having to deal with GAP version numbers), but right now there are 11 archives, so we would need 11 such steps (twice as many if you also want the .sha256 files). So this is cumbersome. Also, upload-artifact always zips all artifacts, even those which are already zips. Looking at the API docs I suspect this is even a limitation of the GitHub Actions artifacts system -- so perhaps we should drop the idea of using these "artifacts". But in that case, we'd need another place to upload nightlies -- e.g. a fixed tag nightlies (but then we also must make sure to clear out obsolete tarballs from time to time -- or just always delete all before uploading new ones; which is a bit of a pity, as being able to download a bunch of nightly builds to find the one where a regression was introduced can be powerful... OTOH as long as we don't provide any binaries, one can just do that with git bisect...) aaaaanyway, what I really care about for now is doing an actual release, making nightly builds available is "just" a bonus

[fingolfin]

I am closing this for the moment to avoid unnecessary CI runs here while I debug