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

See swiftlang/github-workflows#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 <[email protected]>

Author: incertum

.github/workflows/main.yml

@@ -1,5 +1,8 @@
 name: Main
 
+permissions:
+  contents: read
+
 on:
   push:
     branches: [main]

.github/workflows/pull_request.yml

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

.github/workflows/pull_request_label.yml

@@ -1,5 +1,8 @@
 name: PR label
 
+permissions:
+  contents: read
+
 on:
   pull_request:
     types: [labeled, unlabeled, opened, reopened, synchronize]