Apply concurrency control to swift-package-test, cancelling previously running workflows of the same kind

[TTOzzi]

Hello! 👋
This change is derived from swiftlang/swift-format#976.
It adds concurrency control to ensure that only one active workflow is running per pull request, preventing duplicate workflow executions for open PRs.

[TTOzzi]

It seems that in workflows like this one, where multiple swift_package_test jobs are executed, they share the same concurrency group ID, which causes them to cancel each other 🤔

[TTOzzi]

Currently, when the swift_package_test workflow is used by multiple jobs within a parent workflow, it cannot access information about the specific job that called it. As a result, the concurrency group ID becomes the same across jobs, causing them to be treated as duplicates and canceled.

I’ve tried several approaches based on GitHub’s documentation, but so far, it seems the only way to avoid this is to explicitly pass a unique identifier from each job in the parent workflow to the swift_package_test.

However, requiring such an ID as an input parameter would affect all existing workflows that use swift_package_test, essentially defeating the purpose by shifting the concurrency logic back to each individual job.

[TTOzzi]

As long as there are cases where swift_package_test is called from multiple jobs within the same workflow, it seems difficult to handle concurrency in a centralized way 😞
I'll go back to the original PR.

[TTOzzi]

While I could tell which PR it was and whether it was the linux-build or windows-build job inside swift_package_test, there was no way — using only the information available within swift_package_test — to determine whether it was triggered from tests_with_docker or tests_without_docker in the parent workflow.