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

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[tcompa]

@lorenzocerrone if you want to ignore the reported cache issue you can do so with this patch

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 4acfac1..cd10cf8 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -83,7 +83,7 @@ jobs:
         with:
           environments: ${{ matrix.environment }}
 
-      - name: Restore shared data cache
+      - name: Restore shared data cache # zizmor: ignore[cache-poisoning]
         id: cache-data
         uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with: