Build Docker images for various platforms in a matrix strategy

[jsf9k]

🗣 Description

This pull request modifies the build.yml GitHub Actions workflow to build the Docker images for the various supported platforms in a matrix strategy. The idea for this change was motivated by a conversation between @mcdonnnj and me.

N.B.: This pull request is somewhat of a breaking change, as the matrix strategy breaks the previous single monolithic multi-platform build into a bundle of individual single-platform builds.

N.B.: I have done away with the PLATFORMS environment variable and explicitly listed the available platforms in the GitHub Actions workflow yml file. This is because I didn't see a way to easily convert a comma-delimited list of platforms stored in an environment variable into a YML list inside the workflow. If others are able to figure that out, and we think there is benefit in having the platforms stored in an environment variable, then I'm not opposed to changing it back.

💭 Motivation and context

This change makes it easier to temporarily drop support for a failing platform that we cannot fix, as we are currently experiencing with #64.

🧪 Testing

All pre-commit hooks and GitHub Actions pass.

✅ Checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All new and existing tests pass.

[jsf9k]

@mcdonnnj pointed out to me that this PR is incorrect as it stands. Each job in the matrix of platform jobs creates a platform-specific Docker image with a manifest supporting that one single platform, and whichever job finishes last wins. (The late bird gets the worm.)

What we actually want is to run the matrix of platform jobs to create local Docker images, then create a list of all the platform jobs that succeeded and use that to create an appropriate manifest. This is probably too much work for us to take on right now, especially since we can more easily resolve #64 by simply removing s390x from the list of platforms. The basic idea might make a good feature request issue for docker/build-push-action.

So my current thought is to close this PR unmerged, write up an issue for docker/build-push-action, and resolve #64 the simpler way described in the previous paragraph. What do you think @felddy and @mcdonnnj?