GitHub Workflows security hardening

[sashashura]

Issue - #10510

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted.
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

[emteknetnz]

Peer review note - similar PR on laravel from author was recently merged - laravel/laravel#5992

If we accept this we'll need to roll this out to all the other supported silverstripe modules

[sashashura]

An example of a recent workflow run with unrestricted permissions:

[emteknetnz]

I'm assuming that was run on a push rather than a pull_request event - push events should have write permissions while pull_request events should have read-only permissions

The token has write permissions to a number of [API endpoints](https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token) except in the case of pull requests from forks which are always read
https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

[sashashura]

That one was on schedule, but the same applies to push. On pull_request is safe. The threat model is the same as explained in the already referenced laravel/laravel#5992 - a potential tool or dependency compromise is independent from the workflow run, it just happens that pushes happen often and each time the workflow runs with unnecessarily wide permissions, that increases the potential impact.

[GuySartorelli]

Thank you for this contribution.
We won't be merging this PR as-is - we manage a lot of repositories and have a custom tool for making wide-spread changes across them. If we decide to go forward with this security hardening it will be done across all of our repositories using that tool.