…st of the workflow run

And other changes aimed at minimising deployment and maintenance
overhead. Ideally, one shouldn't need to update this workflow file for
new Python versions, and should not need to edit it at all for each
repository it is deployed to - the workflow file can be deployed
as-is.

* No longer need to specify PURE or NOARCH - this will be introspected
  during the configure job.
* No longer need to specify the package name, it will be introspected
  during the configure job.
* No longer need to specify which versions of Python to build for in the
  case of a non-pure wheel or non-noarch conda package - the configure
  job will set variables to target all currently-supported Python
  versions.
* Use `cibuildwheel` to build impure wheels on all platforms instead of
  only `manylinux` for Linux (now deprecated).
* No longer need to adjust list of OSs to run jobs on - this will be
  determined automatically based on pure/noarch status.
* No longer need to specify the repository in job-level if-statements to
  prevent jobs running on forks. Instead, jobs simply do run on forks,
  but upload steps will be skipped if the relevant secrets are absent
* Removed "ignore tags" step that was designed to prevent running the
  workflow twice on a commit with tags and uploading twice to the
  Anaconda test label, resulting in an error. Instead, we upload
  releases to real PyPI and Anaconda main label,  and non-releases to
  test PyPI and anaconda test label so there is no duplication. Also we
  add the `--skip-existing` flag to anaconda uploads since sometimes
  you just need to re-run workflows anyway, this should be idempotent
  and not crash simply because some previous uploads succeeded.
* Add `if-no-files-found: error` to all `Upload Artifact` actions, with
  step-level `if` statements so they only run when we expect output.
  This reduces the incidence of failed runs that produced no artifacts
  appearing successful.
* Fix macOS impure conda builds. These previously didn't work at all on
  the newer macOS runners, because conda's compiler toolchains are
  super duper out of date. Instead, we use conda-forge toolchains by
  installing miniforge instead of miniconda.
* Use bash to build conda packages on Windows, same as Linux/macOS - it
  was never necessary to use cmd.exe in the first place, I think doing
  so just masked the path-length limit problem for some packages, which
  we now address by setting the conda build root path to a directory
  with a very short filepath.

It was not possible to get rid of absolutely all configuration, but at
least we can obviate the need to edit the workflow file itself, which
should now be able to be identical across repositories. To have this
workflow do anaconda uploads, you'll need to set the `ANACONDA_USER`
variable in your repository or organisation's Actions variables
(similar to how secrets are set). I've already done this for the
`labscript-suite` organisation.

hard-code release-branch-semver and no-local-version

These are no longer configured to be different in CI than locally

Drop minimum version requirements for build requirements where those
versions are now several years old

Since we can no longer use the presence of TestPyPI and PyPI API keys to
know if we should attempt to upload releases (i.e. we're not running in
a fork), we instead do need some explicit configuration.

Rather than do this all in repository variables, we do it in a config
file in the workflow directory.

RELEASE_REPO is set to the repository releases should be made from
(otherwise uploads are skipped).

For consistency, ANACONDA_USER is set here too rather than as a
repository variable.

For completeness everything else is configurable there too.

Re-add the "ignore tags" step - with fixes since it was incorrect given
recent changes to the workflow `on:` configuration. It is needed due to
race conditions - we are cloning the repo in multiple jobs and a tag
could appear in between them, leading to version inconsistencies.