Simplification of CI system

### Describe new/missing feature

The CI has become a bit difficult to maintain and this is likely to increase as we move towards GPU support. I think it needs a cleanup/simplification.

Spack CI:

- The Spack-based CI is harmonised into a single runner file, parameterised over base platform and dependency sets specified in multiple static Spack `.yaml` files, rather than being written as `spack add` commands.
- Each Spack environment file would have a specific written reason for its existence in terms of covering a good set of build/testing combinations (this would be the first step, infact).
- FEniCS components would still be built and tested using regular commands, not Spack.

For native CI:

- Native macOS (Homebrew plus cached PETSc), Ubuntu (system packages, no PETSc) and Windows (vcpkg, no PETSc) would remain.

For Docker:

- Docker-based CI is removed.
- Hence, the gigantic images with all combinations of PETSc are removed.
- Dockerfiles and images are simplified with the main goal to provide the best end-user experience for `dolfinx:nightly` and `dolfinx:stable`. This means using as many pre-built Ubuntu and pypi packages as possible, possibly even PETSc (we will see).
- I would propose keeping the split between `dev-env` and `dolfinx:nightly/stable` - it's been useful for debugging with inexperienced users and reduces download times.

Some disadvantages:

- Nearly full reliance on Spack. We do now have the ability to hot fix Spack recipes at: https://github.com/FEniCS/spack-fenics without having to maintain a fork of upstream Spack packages.
- Downstream users of our testing images will be annoyed - however, these were never promoted as a public facing resource.
- In terms of replacing the Docker images, there is the potential to educate users on using Spack to generate Dockerfiles. https://spack.readthedocs.io/en/latest/containers.html#generating-recipes-for-docker-and-singularity

### Suggested user interface

```python3

```