Add pyrefly type checking.

[AndreasBackx]

This adds pyrefly to the type checking. I'm working on a lot of typing improvements and it's helpful to have a third one because it's sometimes not really clear why pyright is saying typing is wrong. It already is saying some things are incorrect which I'm planning to look into.

I hope it's not going to lead to a conflict of typing issues, and if so, we can review this more closely in the future.

As of writing I've not fixed the typing issues, but I'll publish the PR once done.

[kdeldycke]

Typing is not my forte. In my projects I just fire up a mypy and try to make it happy. Waiting for ty to mature a bit and I'll switch to it in the future.

So I'll let other give feedback on that topic and I'll just follow the movement! 😁

[davidism]

I'd prefer to stick to mypy for now. If we're still testing with pyright, we can remove that; it was added when I thought we needed to test with all of them. But really, we just need to test with mypy for our own code, and pyright --verifytypes to know that we export complete types for others to use in their code.

I know pyrefly is working on an export verifcation as well, but I tried last month and both its type checking and verifcation weren't ready yet. Same with ty. I'm really interested in those two, but prefer we wait for now. mypy, for all its quirks, is very mature and actively maintained.

[davidism]

Regarding static typing in general, remember: annotations are there to serve us and our users, not the other way around. Click (and all of Pallets) predates static typing, and we would design it differently today to be better typed. So if we're doing something weird and typing can't express it (or it's too complicated to figure out), you're fine adding # type: ignore[error code] comments to insist that a return type is what we say it is, that a use of an argument is correct, etc.