Drop dependency on jaraco.context (+backports)

[Avasam]

It seems overkill to pull in jaraco.context and its dependencies just for that one function.
This should also allows removing both jaraco.context and backports from setuptools's vendored dependencies as they were both only transitive from jaraco.context

Relates to:

• Stop vendoring packages pypa/setuptools#2825
• [BUG] 71.0.0 fails with backports.tarfile on Python 3.8 when other backports imported pypa/setuptools#4476
• [BUG] 71.x fails with backports.tarfile with conda-installed backports present pypa/setuptools#4508
• [BUG] 71.0.4 and 71.1.0 fail with ImportError: cannot import name 'tarfile' from 'backports' pypa/setuptools#4509

[jaraco]

Thanks for the proposal.

My intention with authoring ExceptionTrap was to provide a way to model in a one line expression (once Python 3.8 is dropped) what's done in four lines plus two new blocks plus two return values and two literals. I'd hope over time to re-use this pattern in more places, rather than limit the usage of it (and then implicitly put a constraint that it can't be expanded).

Of course it's possible to write primitive, imperative code, but I'm aiming to elevate the ecosystem by providing re-usable sophisticated abstractions like ExceptionTrap. This abstraction was inspired by the popular RaisesContext used by pytest, but generalized to be useful in a non-test context.

I think I'd be more inclined to remove jaraco.context.tarfile, which creates the dependency on backports.tarfile, or move it to another library, but that approach too doesn't generalize well - it implies that every bit of functionality that depends on some other library should itself be split out into a separate library in order to limit the number of transitive dependencies.

This proposed change also implies that compose and method_cache should also be inlined as imperative behavior in order to remove the dependency on jaraco.functools, a slippery slope to "just don't have any dependencies and re-implement the minimum subset of the behaviors you need in each and every project."

Since I want to reduce code duplication, I'm declining this change.