This script is now developed and maintained in a dedicated repository for such reusable project assets. This means that
there is no need for its test code to be checked in to this repository. I did this by accident after having failed to
follow the installation instructions carefully and am now correcting my mistake.

The `workflow_dispatch` event allows triggering the workflow via the GitHub web interface. This makes it easy to trigger
an immediate workflow run after some relevant external change.
The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an
immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't
have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason
against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but
not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows
manually.

The official GitHub Actions documentation specifies the hosted macOS runner names use the `macos` prefix. Although the
non-compliant case previously in use clearly does work, there is no guarantee it will continue to do so, so it's safest
to follow the documentation exactly.

No functional change, and neither is necessarily superior, but this is how it is in the "template", and so it must be
here as well.

Although the other works as well, this is the style specified in the official GitHub Actions reference and used in the
"template" workflow.

There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml`
exclusively for YAML files, standardized "template" workflows which might be applied to projects that have established
the use of the other extension. It will be most flexible if it supports both.