Generate workflow files with a Jinja template

[ocelotl]

Fixes #2686

The idea behind this PR is to delete our current test and lint workflow files and replace them with automatically generated workflow files.

This automatically generated file gets its information directly from tox.ini, removing the duplication of test running information in tox.ini and in the Github workflow files.

To achieve this, I have added a Jinja2 template that is used to generate the new workflow file. The resulting workflow file does not use a Github matrix. This is intentional, a Github matrix only supports 256 jobs, which had forced us to have 2 almost identical workflow files. With this new approach we only need one huge file.

I also cleaned up the information that is displayed in the web browser, so jobs now have more user-friendly names.

I also added a check that makes sure that the automatically generated workflow file is up to date with every PR that modifies the automatically generated workflow files so that we don't miss adding any necessary changes to this file.

I also removed the step where we cache the tox environment. Since every tox run happens in a separate runner, I think there is no point in saving this cache.

[ocelotl]

We need the same for lint, I'll do that in a new PR.

[ocelotl]

Bit of nit/soft comment for consideration: it looks like you can use a github workflow to generate the matrix via JSON: kenmuse.com/blog/dynamic-build-matrices-in-github-actions

This would avoid having a separate template with text munging and the script you added could instead output JSON. A lot of what the template does is "reimplementing" GHA features like variable interpolation and matrices. Any thoughts?

Ah, yes, I remembered this when I saw this uses $GITHUB_OUTPUT. This was actually my first approach, I tried and then moved a way from this approach. What I realized was that the matrix approach has a few disadvantages:

1. Need to produce a exclude section: so, the tox.ini file says which python versions are used for every package. It doesn't say which python versions are not used for every package. We could of course produce an exclude section based on this information but I find it cleaner to only produce jobs that are to be run instead of "producing" them all and then removing the ones that are not to be executed.
2. No fine control on the workflow files: Sometimes we don't want to follow the exact same steps for every job. For example, in the core repo, we have a step that only gets executed if the underlying OS is Windows (configuring git to allow for long file names). We are actually running this step in Ubuntu, just skipping its contents. It is cleaner not to have it at all if the OS is Ubuntu, a Jinja template allows us to do that, a matrix doesn't. Also, we are using templates in this PR for consistency for all the jobs (lint, docker tests, etc) and in some of those jobs we also need the template to do something particular for different jobs, so we need templates for this reason too.
3. The result is obvious. Once the (huge, yes) workflow file is created, it is completely obvious for whoever reads it what is happening in CI, there is no need to figure out the matrix. This approach requires the workflow files to be generated by hand in some PRs that will introduce things like new packages or adding support for a python version for a particular package, etc. So, I added a check that works in the same way as the one we already have for tox -e generate, which will fail CI if the user has not submitted the generated workflow files in the PR.

[xrmx]

I am sympathetic to Aaron concerns regarding the obvious huge listing vs the compactness of the gh matrix but once we are generating the workflows if we see areas of improvements we can iterate on it.