Add support for anyio.get_cancelled_exc_class() in TRIO102, 103 and 104.

[jakkdl]

Fixes #122

rewrote critical_except a bit as I updated it, in large part because I personally failed to read the old version of the code 😇
Fix #106 for TRIO102 (#109 only fixed TRIO103 & TRIO104)
Thanks to #125 it was quite smooth to add a different suggestion for TRIO103 when anyio is the primary library.
As I started to write a assert_correct_message test helper I realized I had pretty bad code duplication, so checking of column, message and args are now all handled in assert_correct_attribute.
Improved how ignore_column is handled in anyio tests.
A slew of tests being moved around and modified and stuff so the necessary eval_files are handled with trio/anyio as appropriate. And some additional ones for #106+TRIO102

[jakkdl]

Added a separate error message when both are available.

But I'm unsure how to handle TRIO103 when both are imported, should bare excepts require that both have been handled in that case?
See the new trio103_both_imported.py which tests for such cases.

[Zac-HD]

This looks good to me!

Some non-blocking nitpicks below; I intend to try it out on some anyio libraries to check that the results looks reasonable, and then merge if there's no obvious problems.

Given that LibCST support seems close-ish, if it's noisy I'll wait for auto-fixes before recommending to OSS maintainers.

[Zac-HD]

Let's canonicalize this, so we only have to worry about one ordering.

I'd also recommend a tuple literal rather than the (not-valid-at-runtime) |.

[jakkdl]

I should maybe replace self.library with a tuple instead of a string, but there's semi-intentionally an ordering. Running your project with --anyio and importing trio for a file, vs importing trio in a global scope and anyio in a local scope. (or more reasonable, if it did matter in other contexts and there was a flag for it, running the project with a --trio flag and importing anyio in a file), could plausibly lead to different behaviour / error messages. But writing this out it seems so esoteric/far-fetched/does-not-matter-with-current-implementation I'll disregard that for now.

[jakkdl]

I fiddled a bit with this and ... maybe the code is better now? Idk, I'll likely fiddle around with this more when I write more library-specific/dependent code

[Zac-HD]

...safe, yes, but also redundant with the except BaseException: 🤔

[jakkdl]

I didn't actually know that exceptions have to inherit from BaseException, interesting. I opened PyCQA/flake8-bugbear#349 in case anybody cares for it.

[Zac-HD]

I'm unsure how to handle TRIO103 when both are imported, should bare excepts require that both have been handled in that case?

I think in this case it's safe to just catch anyio.get_cancelled_exc_class(), because if you're actually running Trio code that will return trio.Cancelled.

[jakkdl]

I'm unsure how to handle TRIO103 when both are imported, should bare excepts require that both have been handled in that case?

I think in this case it's safe to just catch anyio.get_cancelled_exc_class(), because if you're actually running Trio code that will return trio.Cancelled.

If you're running all three async libraries, and anyio's current backend is asyncio, and in the try: statement stuff is ran that could either raise trio.Cancelled or anyio.get_cancelled_exc_class(), it might bork? But that seems weird enough that I think not raising false alarms is more important.

[jakkdl]

addressed nitpicks and rebased on top of main to ensure coverage.