chore: restrict GitHub workflow permissions - future-proof (#781)

See https://github.com/swiftlang/github-workflows/issues/167 for
additional context

This approach aligns with security best practices, as detailed in the
following documentation:

-
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
-
https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#defining-access-for-the-github_token-scopes
-
https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/


The default GITHUB_TOKEN permissions are defined at the repository
level. This PR modifies the workflow-level overrides to conform to
OpenSSF best practices -> defense in depth.

Allow me to quote OpenSSF:

https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

> The highest score is awarded when the permissions definitions in each
workflow's yaml file are set as read-only at the top level and the
required write permissions are declared at the run-level.”

> Remediation steps
> - Set top-level permissions as read-all or contents: read as described
in GitHub's documentation.
> - Set any required write permissions at the job-level. Only set the
permissions required for that job; do not set permissions: write-all at
the job level.


Compare to the LLVM project:

Top-level: contents read, e.g.
https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L3-L4
-> this makes it future-proof

Job-level: Allow write permissions as needed, e.g.
https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L53-L58

Signed-off-by: Melissa Kilby <mkilby@apple.com>

.github/workflows/common.yml

@@ -1,5 +1,8 @@
 name: container project - common jobs
 
+permissions:
+  contents: read
+
 on:
   workflow_call:
     inputs:

.github/workflows/docs-release.yml

@@ -1,6 +1,10 @@
 # Manual workflow for releasing docs ad-hoc. Workflow can only be run for main or release branches.
 # Workflow does NOT publish a release of container.
 name: Deploy application website
+
+permissions:
+  contents: read
+
 on:
   workflow_dispatch:
 

.github/workflows/merge-build.yml

@@ -1,5 +1,8 @@
 name: container project - merge build
 
+permissions:
+  contents: read
+
 on:
   push:
     branches:

.github/workflows/pr-build.yml

@@ -1,5 +1,8 @@
 name: container project - PR build
 
+permissions:
+  contents: read
+
 on:
   pull_request:
     types: [opened, reopened, synchronize]

.github/workflows/release-build.yml

@@ -1,5 +1,8 @@
 name: container project - release build
 
+permissions:
+  contents: read
+
 on:
   push:
     tags:

.github/workflows/release.yml

@@ -1,5 +1,8 @@
 name: container project - release build
 
+permissions:
+  contents: read
+
 on:
   push:
     tags: