CI: Refactor sdist workflow and add setup-python action
Smaller version of https://github.com/pandas-dev/pandas/pull/46493 according to suggestion in https://github.com/pandas-dev/pandas/pull/46493#issuecomment-1079541210

- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Sorry my comment wasn't clear - I was hoping that _each_ bullet point would be a separate PR. @mroeschke recycled this PR for sdist refactoring. The action code also covers some more cases not relevant to sdist but relevant to future PRs. Is the main sdist refactor to add the setup python action or are there independent cleanups that can be separate from the setup action? Good point, I've pushed a reduced version. @mroeschke let me know if I can make this PR smaller to ease reviewing. Thanks for all the nice work with the CI @jonashaag. I see you've got several PRs open, and looks like most of them too big to be merged. Before things start to become too messy, I would suggest if you can create an issue for the refactoring of the CI, with the tasks that you've got in mind, or the final status you're aiming to achieve. And then you can open atomic PRs (without mixing things that can be addressed independently). Also, would be nice to keep closing PRs that aren't relevant anymore (so reviewers don't need to navigate and find the ones that are ready mixed with some that don't require attention anymore).

I understand it may be a bit frustrating to work this way. But in a project as big as pandas, we need to make sure that:
- Everybody, not only you, can properly understand what you're trying to achieve (in a single PR, and in the whole refactoring)
- PRs are easy to review (and it doesn't take a huge amount of time to review, since every feedback iteration would be very time consuming)
- When things go wrong in the future because of changes, it's easy to understand what happened, there are issues explaining what was the general idea, and PRs are atomic, so they can be understood better, and reverted if needed, without having to revert unrelated changes.

Thanks! This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. Is this still relevant @jonashaag or has this been superseded by your other PRs? Superseded.