Attempt to fix erroneous build cancellation

[imjasonh]

Description

Following up on #1858

The theory is that having the concurrency config inside build-images means that each matrix value shares the same concurrency key. If that's the case, the only reason this works at all is that there's some race where tasks that start at the ~same enough time won't cancel each other, but when they start minutes apart, they cancel previously started runs.

With this change, the concurrency key is based on the matrix value, so they should be unique per image x PR-or-commit, and not conflict and cancel previous runs.

Another option would be to move the concurrency config back up to the top level, which would also work (if the theory of what's happening is right), but would mean that there's one large concurrency lock around "building images" and not four fine-grained ones around "building each image", which I think is slightly better -- and will become even better when/if we can get image builds to not take 30+ minutes. 🐢

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes unit tests
• Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.