Github workflow improvements

[matthijskooijman]

While preparing for the 3.0.3 release, I encounted some things in the github workflow that could be improved:

• Fix warning in workflow run: The following actions uses node12 which is deprecated and will be forced to run on node16: actions/checkout@v2, actions/setup-python@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/
• Use --install-deps-from=flathub in the github workflow, so that no longer needs to hardcode the gnome version to be used (also listed in Flatpak improvements #743).
• Release automation: Reset tree for development by automatically adding NEWS.md header and resetting VERSION file.
• Release automation: Automatically create github release, with the NEWS.md content for the release and flatpak build included.
• Prevent duplicate push and pull_request workflow runs.

About the last point, there is currently a push and pull_request trigger for the testing workflow, so they run for direct pushes to all branches, as well as for pullrequests (including pullrequests from third-party repositories, which do not trigger the push trigger). This means that for pullrequests that originate in this repo, the workflow runs twice (almost identically).

I looked around and found two potential solutions:

1. This uses a conditional to suppress the pull_request rule when the source branch is in the same repo: https://github.com/orgs/community/discussions/26940#discussioncomment-6656489
2. This implies to use a third-party script that (through the github API, I believe) figures out the pull request that a push event pushes to, and if there is one, could suppress the push event: https://stackoverflow.com/a/74439898

However, later I realized that both events actually produce slightly different workflow runs: The push event runs with the original version pushed by the contributor, while the pull_request event runs on a automatically created temporary merge commit that merges the PR branch into master. That actually seems valuable - for a PR, it is better to test the result of the PR merge, rather than what the contributor pushed by itself, so I would prefer to suppress the extra push event.

One related observation is that the auto-created merge commit in the pull_request event is of course checked out, so its git hash is used as part of the git describe output that is used as the hamster version inside the produced flatpak build (and in its filename). This is suboptimal, since if you want to later figure out what git revision a build was created from, it contains the hash of a git commit that no longer exists anywhere, and can thus also not be traced back to the original sha. We could "fix" this by checking out the original pushed commit instead, but then we no longer test the merged commit. So maybe the github workflow could do some special handling and produce something like Hamster-deadbeef-merged-into-abcdef.flatpak (and then maybe even include the PR number while we're at it). I'm not sure if we should also do something similar to the version number inside the hamster build (which would require changes to src/hamster/version.py or wscript, since those now prefer the git version if it is available).