CI: Remove redundant sdist workflow
AFAICT: The sdist workflow was essentially similar as the `build_sdist` job in the wheels workflow except it didn't test the sdist cc @lithomas1 
I think the reason that I didn't remove this yet was because we don't have a way of testing that the oldest supported numpy works (on all Python versions).

Not sure if this testing is too relevant now though.

Agreed this would be nice to remove though. It seems the workflow never really _tested_ pandas with the lowest oldest supported, just that `pd.show_versions` worked. It doesn't look like we have any runtime checks for this either.

But as long as we have `oldest-supported-numpy` shouldn't we be okay? > Somehow unrelated. Would it make sense to run the tests on the same jobs we build the wheels? From the release point of view, feels like it'd make sense to test on the CI what's really being released.

I would be +1 to this. It would be great to the have the CI more representative of testing pandas from what users install. We should probably still have a job that tests that pandas can be installed from source and pass the test suite.

> Also, how do you feel about copying the recipe from feedstock to this repo, and having a CI job to build the conda package? That would be nice to avoid having to update the recipe during the release process.

I guess I wouldn't be opposed to this, but IIRC the conda forge build is still triggered from the Github release being created? Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 2.0.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -x -m1 f990ab01ed1991a5ed8be9bc08135fdf78794050
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #52794: CI: Remove redundant sdist workflow'
```

4. Push to a named branch:

```
git push YOURFORK 2.0.x:auto-backport-of-pr-52794-on-2.0.x
```

5. Create a PR against branch 2.0.x, I would have named this PR:

> "Backport PR #52794 on branch 2.0.x (CI: Remove redundant sdist workflow)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                 > I guess I wouldn't be opposed to this, but IIRC the conda forge build is still triggered from the Github release being created?

That was broken for few releases, but for the last one the PR was automatically created. But even if the conda-forge bot creates the PR, the CI for the will fail if changes are needed to the recipe.

The idea is that if for example  you're adding a new required dependency, the conda-forge recipe needs to be updated. Now, we discover this in the middle of the release. Having a CI build in the pandas repo itself that builds the conda package would make the CI fail in the PR where the dependency is added, and the copy of the recipe in the pandas repo will have to be updated. This way, in the release we already have the working recipe that we just need to copy.