Add concurrency key to publish/preview workflows

[penelopeysm]

This PR adds the concurrency key docs to both publish and preview workflows, preventing them from running concurrently. This will help us avoid weird race conditions like the one described in #526, which came about because the preview workflow overwrote changes from the publish workflow.

Additionally, the publish workflow is also given cancel-in-progress: true meaning that if a preview workflow is running, starting a publish workflow will cancel the preview workflow.

This is probably OK because preview workflows run on PRs, and if somebody pushes to main (which triggers the publish workflow), the PR has to incorporate the new changes anyway.

The only downside to this is that there can only be one queued job at any time. So if (for example) three people are working on PRs at the same time and trigger preview workflows, one workflow would run, one workflow would be queued, and one of them would be cancelled. That scenario seems quite unlikely given the level of contributions to the docs, though, and can be fixed fairly easily by manually rerunning the workflow. (This is a weird limitation of GHA, and apparently a fix for this is on GitHub's roadmap, see https://github.com/orgs/community/discussions/41518.)

Closes #526.

CI is failing because I manually cancelled the preview workflow on this PR (it doesn't serve any purpose).

[shravanngoswamii]

That scenario seems quite unlikely given the level of contributions to the docs, though, and can be fixed fairly easily by manually rerunning the workflow.

Quite agreeable!

[shravanngoswamii]

Looks good to me! Thank you, @penelopeysm!