Applying more Ruff groups to this repository

[Avasam]

The current selection of Ruff rules comes as a direct translation from when we were using isort, pyupgrade, pycln, Flake8, and some plugins.
It made perfect sense at the time to restrict ourselves to only the most necessary rules, as additional linters and tooling to be installed and run could mean an increase in CI runtime, security risks, upgrade maintenance, and complications between incompatible versions of libraries.

But with Ruff, the context is completely different. It is so fast than any additional rule group is negligible on the runtime and it's a single dependency. Which means that we could enable more rule groups w/o much concerns to help keep our growing non-stubs code up to the best standards. And explore more lints that could be beneficial to stubs.

As a side effect, we get to test various Ruff rules on a very 3rd-party type-stubs-driven repository, helping catch edge-cases and rules that don't belong in that context. This, in my opinion, would further bolster the existing collaboration between Ruff and typeshed, as well as indirectly help the Python typing community that also uses Ruff.

---

I'm already ready with an experiment PR to see the width and scale of changes this would entail with nearly all rules enabled.
Avasam#39 (not something to be reviewed, just a launching point for me, like a possible "todo list")
Of course I would go incrementally: starting with those that already pass as-is, then those covered by autofixes, individually splitting off the more massive ones, finishing with the manual interventions.

[AlexWaygood]

It makes sense to me to enable some more ruff rules on this repository — some of the changes in Avasam#39 look very useful! Some look not-so-useful to me, though ;)

I think I'd definitely want to review each rule group being added on its own merits. A lot of ruff's rules are really useful, but not all of them make sense for every codebase. Some are extremely opinionated and enforce patterns that many would disagree with; some don't make sense at all for code in some domains; and some make sense in theory but are so nitpicky that they're pretty annoying to have enforced in CI without autofixes considering the benefits they actually bring.