Remove (Deprecate??) TrioDeprecationWarning

[jakkdl]

I was thinking about whether to use DeprecationWarning or TrioDeprecationWarning in #2989, when I decided to actually figure out what the difference is and why TrioDeprecationWarning is a thing. It lines up with https://bugs.python.org/issue24294, which was resolved with https://peps.python.org/pep-0565/ and released in python3.7

Since we don't support 3.6 and earlier, the original reason for its existence is gone, so we at the very least should make it inherit from DeprecationWarning instead of FutureWarning and update the docstring. Or we go even further and remove TrioDeprecationWarning entirely (with an intermediate period of making it a pure alias of DeprecationWarning but emitting a DeprecationWarning).
Having helper methods linking to issues and stuff is still helpful though, and after recent discussions in Gitter we maybe also want a parameter for how long we're planning to keep the deprecated thing around before it gets removed.

[A5rocks]

I was concerned for a bit but backwards compaibility is trivial for this. The only times TrioDeprecationWarning will happen is for current deprecations that should disappear in max 2 releases (well, except strict_exception_groups... not sure what to do for that).

So we just, for every new deprecation, start raising DeprecationWarning instead (simple kwarg on warn_deprecated?). The only case I think that might disrupt is if someone specifically wants to ignore all deprecations from Trio and decided that ignoring TrioDeprecationWarning generally is good. But I'm fine breaking their workflow, if that person exists.

[jakkdl]

We could just do the equivalent of

import warnings

# this is in src/trio/_deprecate
MyTrioDeprecationWarning = DeprecationWarning

# and this is what people are currently doing, suppressing TrioDeprecationWarning
with warnings.catch_warnings():
    warnings.filterwarnings('ignore', category=MyTrioDeprecationWarning)
    # It still silences DeprecationWarning
    warnings.warn(DeprecationWarning("hello"))

And the only warning suppression that would break is if people are filtering on FutureWarning. But maybe people are doing that, since specifying custom warning categories on the command line is non-trivial (maybe not even posssible? idk I couldn't quickly figure it out at least)

$ python -W ignore::FutureWarning foo.py         
$ python -W ignore::TrioDeprecationWarning foo.py
Invalid -W option ignored: unknown warning category: 'TrioDeprecationWarning'
/home/h/Git/trio/deprecate_deprecationwarning/foo.py:10: TrioDeprecationWarning: trio.run(..., strict_exception_groups=False) is deprecated since Trio 0.24.1; use the default value of True and rewrite exception handlers to handle ExceptionGroups instead (https://github.com/python-trio/trio/issues/2929)
  trio.run(foo, strict_exception_groups=False)

We should maybe ask in gitter & search repos on github.

The current deprecationwarnings, other than strict_exception_groups are to_thread.run_sync(cancellable=...) #2841 and open_tcp_listeners(backlog=math.inf) #2842.

[jakkdl]

I partly resolved this in #2989, by adding a use_triodeprecationwarning parameter that defaults to False; and updating current deprecations to pass True. So only thing remaining is if we want to do anything to current deprecations.

[A5rocks]

I think current deprecations are fine. They'll be gone in a couple years.