Motivation
----------

#158 added Swift 6.2 flags to the `main` workflow, but the
`pull_request` workflow has a separate list of flags which was not
updated.

Modifications
-------------

Update `pull_request` workflow to match `main`.

Result
------

Correct 6.2 flags will be applied to pull request workflow runs.

Test Plan
---------

This PR will fail because the integration and end-to-end tests does
still install the 6.1 Static SDK.

Motivation
----------

End to end and integration tests are failing because the underlying
Swift CI runner has been updated to use Swift 6.2 but these tests
install the 6.1 release of the Static Linux SDK.

Modifications
-------------

Update end to end and integration workflows to install the the 6.2
release of the Static Linux SDK.

Result
------

All tests will pass again.

Test Plan
---------

All existing tests pass again.

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 <mkilby@apple.com>

Motivation
----------

Swift Crypto doesn't change its public API much between major releases
and recommends to use a range from "1.0.0" ..< "5.0.0"

Modifications
-------------

Update the dependency range to "1.0.0" ..< "5.0.0" as swift-crypto
recommends

Result
------

Projects can use the latest swift-crypto