refactor: remaining 3.10+ cleanup

[vmphase]

Summary

Follow-up cleanup to the automated pyupgrade --py310-plus pass in #2988, covering things that tool didn't handle:

• Replace typing_extensions.ParamSpec with typing.ParamSpec
• Replace deprecated typing.Deque/Deque[...] with collections.deque/deque[...]
• Replace collections.OrderedDict with plain dict (insertion-orderguaranteed since 3.7)
• Drop the hasattr(types, "UnionType") guard
• Convert big if/elif chain to match/case
• Remove PY_310 version check, pre-3.10 branch, utils.flatten_literal_params and utils.classproperty

Information

• This PR fixes an issue.
• This PR adds something new (e.g. new method or parameters).
• This PR is a breaking change (e.g. methods or parameters removed/renamed).
• This PR is not a code change (e.g. documentation, README, typehinting,
  examples, ...).

Checklist

• I have searched the open pull requests for duplicates.
• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes.
• If type: ignore comments were used, a comment is also left explaining why.
• I have updated the changelog to include these changes.
• I have read the Contributing Guidelines.
• AI Usage has been disclosed.
  • If AI has been used, I understand fully what the code does

[pycord-app]

Thanks for opening this pull request!
Please make sure you have read the Contributing Guidelines and Code of Conduct.

This pull request can be checked-out with:

git fetch origin pull/3323/head:pr-3323
git checkout pr-3323

This pull request can be installed with:

pip install git+https://github.com/Pycord-Development/pycord@refs/pull/3323/head

[vmphase]

I didn't update the changelog because all the changes are internal.
Furthermore, the #2988's changelog was not updated as well.

[Paillat-dev]

Also imo this hurts readability since it's not proper equivalence.

[vmphase]

I mostly went for it since it removes the repeated elif v < boilerplate. Under the hood this compiles to the same sequential guard evaluation as the if-elif chain, so there's no difference. I think the reduced repetition is worth it here, and PEP 634 explicitly documents guard clauses (case x if ...) as valid usage.

[Paillat-dev]

Valid sure but this is more confusing in this case. In my mind case x if is for specific edge cases, not 99% of the conditions. In this case it is just more messy.

[vmphase]

That's not an actual convention and I think this comes down to preference rather than a correctness. Nothing in PEP63* suggests guards should stay rare relative to structural cases, and for a scalar subject like this there's no structural pattern to lean on in the first place, so guard-per-case is just what matching an int naturally looks like.

[Paillat-dev]

Of course it's preference.