Dynamically generate the matrix

This plugin has three functions:

1. Make SBT the source of truth for the Github Actions matrix of Scala versions, etc.
2. A DSL for defining your entire workflow from within your SBT build
3. A standard set of workflows that works well for most projects, using sbt-ci-release.

If one only needed (3), an SBT plugin would be unnecessary. (2) is very nice for those that are more comfortable doing things that way. And once you're doing things that way, the whole sbt githubWorkflowGenerate / sbt githubWorkflowCheck becomes necessary.

And it is a pain point, because it's too easy to forget to run sbt githubWorkflowGenerate. Fortunately Scala Steward knows to run it.

But the reality is that the value for most people is probably (1). And I think it may be possible to support without the whole sbt githubWorkflowGenerate / sbt githubWorkflowCheck dance.

I found a few articles about how to define a dynamic matrix. Here is one of them: https://brunoscheufler.com/blog/2021-10-09-generating-dynamic-github-actions-workflows-with-the-job-matrix-strategy

The basic idea is that an earlier step can generate output that the next step can parse as its matrix.

So there could be an SBT task to print out the matrix data, and the workflow could be written to use it to define the matrix. Then every time the Scala versions change or you add a subproject, ci.yml doesn't have to change.

Start by reviewing the existing sbt githubWorkflowGenerate and sbt githubWorkflowCheck commands and the ci.yml workflow. Compare the proposed dynamic matrix approach with the current workflow-generation process, using the linked article as background. Done means Scala version and subproject changes can update the matrix without manually changing ci.yml.