Merge simple type annotations from typeshed

[Avasam]

Summary of changes

Please review and merge first: #4505 Done
Merging #4581 and #4584 first will reduce changes in this PR Done
It's important to validate this PR with mypy, let's re-enable it first and fix existing failures: #4604

Not done in this PR:

• Abstract methods and classes: Mark abstract base classes and methods #4503
• @overload: Merge overloaded method definitions from typeshed #4506
• return types
• AbstractSandbox's dynamically created methods
• expanded *args & **kwargs, @type_check_only, and other TypedDict from typeshed

Step 6.1 of #2345 (comment)

Pull Request Checklist

• Changes have tests (no new tests, existing static tests should pass)
• News fragment added in newsfragments/. (nothing user-facing as static typing users would still be using types-setuptools)
  (See documentation for details)

[Avasam]

From @abravalheri https://github.com/pypa/setuptools/pull/4505/files#r1709465928

Jason might have added support for PathLikesources recently in pypa/distutils#237 (v72.2.0/setuptools/_distutils/extension.py#L29).

(PS.: granted they are incompatible with SETUPTOOLS_USE_DISTUTILS=stdlib but that is a deprecated code path).

[abravalheri]

It is likely here that requirements and the return value are both list[str]. Not sure how the type-checking would react to that though...

[Avasam]

Doesn't cause any issue. I didn't add annotations to _get_build_requires because it's not typed in typeshed. config_settings param being typed is incidental to adding all _ConfigSettings.

But since you're mentioning it here and it's not an issue, I've added the type annotation to requirements param

[Avasam]

@abravalheri I'll answer a couple comments at once:

• I have a handful of TypeAliases unnecessarily duplicated behind TYPE_CHECKING check whilst a from __future__ import annotations is sufficient to use an annotation that doesn't exist at runtime. So those should be simplified now.
• As quickly mentioned in the PR description, and described in my step-by-step plan in Add type hints to setuptools #2345 (comment), I purposefully avoided adding return type annotations here. I plan on merging return annotations from typeshed as a direct follow-up. Then re-enabling ANN2 checks for setuptools.

[Avasam]

I don't feel like this alias brings anything of value:

• It doesn't work around any runtime issue
• It doesn't abstract away any complexity
• It's not clearer than the type it's aliasing, or doesn't help explain it
• It's barely any more concise (because it's using a shorthand instead of being clear and explicit)

In fact, it might actually hurt understandability as a dev can reasonably assume that the alias might be abstracting a more complex type and have to check what it is, rather than immediately understanding it's Iterator[str]

But it's not private. Could we maybe deprecate it ?