Introducing a `pkg_resources` package for `setuptools >=82` compatibility

### Your question:

[Setuptools 82 removed the `pkg_resources` package](https://setuptools.pypa.io/en/stable/history.html#v82-0-0). However, a lot of packages out there still require it. Right now, feedstocks are starting to pin `setuptools <82` which is a suboptimal solution.

Upstream has [shown some understanding for the request to package it separately back in February](https://github.com/pypa/setuptools/issues/863#issuecomment-3873020195), but things didn't move much from there.

To ease things on CF side, I'd like to propose creating our own `pkg_resources` package with the code from setuptools 81.0.0 release. The way I see it, we could either:

- create it as a separate feedstock
- create it as an additional output in `setuptools-feedstock`

Either way, I'm willing to step up as the maintainer. In the latter case, I'd propose branching `setuptools-feedstock` at 81.0.0, and creating a new build split to two outputs: `setuptools` and `pkg_resources`. For backwards compatibility, `setuptools 81.0.0` would then run-depend on `pkg_resources`.

In my opinion, the two important advantages of doing that would be:

1. Avoiding proliferating the pin all over the place.
2. Avoiding a run-dependency on whole `setuptools` (additionally pinned to an old version) where only `pkg_resources` are necessary.

If upstream eventually releases a separate `pkg_resources` package, we can replace our own with it.

Disclaimer: I've done the same thing in Gentoo, and it has worked well for us so far.

CC @conda-forge/setuptools

Review the setuptools-feedstock setup and the pkg_resources code from the setuptools 81.0.0 release. Compare the separate-feedstock and additional-output approaches described in the issue, then confirm the required compatibility and dependency behavior. Done means a maintained pkg_resources package is available without requiring setuptools newer than the supported split.

Written by the indexing model from the issue text.