initial implementation of ASYNC123

[jakkdl]

messy and imperfect, but should catch most usage and hopefully Ruff can implement this properly 🤞

TODO:

• changelog, bump version
• write documentation
• figure out a name. reraise_child_exception is clean but "child exception" is not established nomenclature. reraise_exception_group_sub_exception? bad_exception_group_flattening?

[Zac-HD]

Implementation and tests look great, thanks @jakkdl!

I've suggested some changes to the docs which I think will give a bit more context on what happens and why it's bad, as well as recommending "don't do this at all" as our top suggestion. Merge when you're happy with it, with or without edits 🙂

[Zac-HD]

Suggested change

	Raising an exception that was inside an `ExceptionGroup` inside the ``except`` handler of that group will set the group as the `__context__` for the exception, which overrides the previous `__context__` that exception had, truncating the context tree. The same is true for ``__cause__`` (unless explicitly setting ``from``) and `__traceback__`. The easiest fix is to `copy.copy` the exception before raising it, but beware that `trio.Cancelled` did not support copying before `trio==0.27.1`.
	Raising one of the contained exceptions will mutate it, replacing the original ``.__context__`` with the group, and erasing the ``.__traceback__``.
	Dropping this information makes diagnosing errors much more difficult.
	We recommend ``raise SomeNewError(...) from group`` if possible; or consider using `copy.copy` to shallow-copy the exception before re-raising (for copyable types), or re-raising the error from outside the `except` block.

[jakkdl]

That's much better, thanks! Just one small nit on it