Workflow Concurrency

[bmos]

What is this change?

• Limit concurrency of pytest, build, and docs-build workflow jobs and entire PR label checker workflow.

Considerations for discussion

• We have been having random intermittent test failures which seem to be most common when we have a lot of concurrently-running runners.
• There are also a lot of runs occurring which may not be necessary (we generally care about the state of the most recent commit to a branch or pr). This change would cancel any earlier iterations of a job on a workflow/branch. Do we think there is utility in having the earlier commits tested individually as well, even if later commits are pushed in quick succession?
• Downside: old commits get a red X if there were skipped jobs, but no failures

How to test the changes (if needed)

• Check that CI jobs run as usual

Breaking Changes

Breaking changes are changes to our public API which may require existing users to change their code. If there are no breaking changes, any existing parsons user should not need to do anything after updating their parsons version.

Does this PR introduce breaking changes?

• label: Breaking change — This PR introduces one or more breaking changes.
• label: Non-breaking change — This PR does not introduce one or more breaking changes.

Details (if needed)

• (List out any changes to the API that may cause breaks for developer implementation.)

[ghost]

Coverage report

This PR does not seem to contain any modification to coverable code.