Don't use too many CI jobs

[agriyakhetarpal]

I don't exactly recall why we chose to run this big array of CI jobs last year, but I think we could cut them down and still not increase CI time too significantly with our testing, and we could even reduce it for that matter. Right now, we have the overhead of our limited concurrency limit of 8 jobs (we're not on a paid plan from GitHub), the fact that the CI jobs check out the repository and the runners are set up and torn down, etc.

If we were to remove the Python version, build backend, and vcs from matrix variables but rather move them into the job's steps, that would help. That is, we can keep reusing actions/setup-python in multiple steps within the same job, and we can move into different directories to run tests against setuptools/hatch + vcs/no-vcs within the same job. That would get us from 64 jobs to 4 jobs (one per platform), and as the rests barely take 15 seconds, an individual CI job would take 120 seconds, and that is surely fine.

[santacodes]

I agree, I think it was set during the GSoC project period. I'll reduce it.

[agriyakhetarpal]

Thank you!