Update github actions and introduce zizmor scanning

[tcompa]

Hi @lorenzocerrone, I'm opening this PR after the discussion I started elsewhere. Depending on your take on this, I can also reduce the scope of the PR and only introduce a subset of changes - let's perhaps review it together.

What is included:

1. There is a new action based on https://docs.zizmor.sh (which is also the tool I used to scan the current ones). Note that this will likely have some warnings, even after the current PR (here is an example of how they look).
2. All 3rd-party actions are pinned to a commit hash, rather than to a mutable tag (ref https://docs.zizmor.sh/audits/#ref-confusion).
3. To keep 3rd-party actions somewhat up-to-date, I configured dependabot so that it creates a PR every quarter, with a grouped update of all relevant actions (and with a 7-days cool-down window).
4. I also pinned the version of tools that are called directly through a run step (I only spotted pipx run check-manifest).
5. I reduced permissions as much as it seemed appropriate - ref https://docs.zizmor.sh/audits/#excessive-permissions.
6. I removed the caching step from the documentation workflow, since it I couldn't find an actual usage of it (maybe I missed it!) and it's best to avoid using caches in workflows that lead to deployments (like publishing the docs, or publishing a release). Ref https://docs.zizmor.sh/audits/#cache-poisoning.

What is still needed:

1. Most importantly: A review that I did not break anything. It's likely that some 3rd-party action has hidden assumption about what permissions they need, and they will break the next time they run. I looked at their docs when available, but often they do not include this information. I can make changes where needed - but I cannot run workflows on this repo and therefore I cannot check myself.
2. Overall: a review of the tradeoffs. On the one hand, if this PR introduces too much development friction we can also relax some constraints. On the other hand, we can also proceed and improve actions a bit further if you'd like to. An example would be replacing the softprops external actions with direct calls to gh release - similar to https://github.com/fractal-analytics-platform/fractal-data/blob/672fc29c09252444620bf90866d8830560e90f39/.github/workflows/github_release.yaml#L61-L64. Or, possibly, review the workflow_run usage.

Checklist before merging

• I added an appropriate entry to CHANGELOG.md