Add type checking to CI
Author: dylwil3
Pull request: no
Labels: name: Feature request

### Feature request

Use, e.g., `pyright` in your CI.

### Motivation

We run `pyright` as part of our CI and find ourselves having to do a lot of `# type:ignore` because of type errors in `transformers`. It would be amazing if you would consider incrementally adopting something like `pyright` in your own CI. It could help catch some type errors for you (looks like there are quite a few open issues around type errors) and would help downstream developers with `transformers` as a dependency keep their projects type safe.

Overview of 30,105 errors and 228 warnings found by pyright:


|Rule | Number of Violations|
|------|---------------------|
|reportArgumentType                  |5738|
|reportAttributeAccessIssue          |4248|
|reportPossiblyUnboundVariable       |4055|
|reportMissingImports                |3998|
|reportOptionalMemberAccess          |3425|
|reportOperatorIssue                 |1289|
|reportReturnType                    |1117|
|reportOptionalOperand               |1091|
|reportIncompatibleMethodOverride    |1026|
|reportAssignmentType                |873|
|reportOptionalSubscript             |854|
|reportCallIssue                     |585|
|reportIndexIssue                    |580|
|reportGeneralTypeIssues             |578|
|reportInvalidTypeForm               |283|
|reportOptionalCall                  |224|
|reportMissingModuleSource           |189|
|reportOptionalIterable              |69|
|reportIncompatibleVariableOverride  |32|
|reportSelfClsParameterName          |19|
|reportUnusedExpression              |12|
|reportInvalidTypeArguments          |12|
|reportFunctionMemberAccess          |11|
|reportUndefinedVariable             |9|
|reportUnsupportedDunderAll          |8|
|reportRedeclaration                 |5|
|reportUnboundVariable               |2|
|reportUnhashable                    |1|

### Your contribution

I'd be happy to help if there were buy-in from the maintainers. I imagine this would be many PRs and done incrementally. By that I mean: we should 
- decide on some subdirectories we care most about, and rules we care most about
- fix type errors there
- add pyright config to check only those rules and directories
- add pyright to the CI
- slowly expand coverage of directories and rules
This could also be a nice `good-first-issue` to encourage new contributions.

Finally, one way to reduce the amount of work is to first make your _linting_ much more aggressive by updating your `ruff` version and running autofixes. When I turn on a bunch of lint rules and run all fixes (and unsafe fixes) it already removes ~1000 `pyright` errors.

Comments:
cc core maintainers @arthurzucker @cyrilvallez, but in general we've treated type hints as "nice but optional" in Transformers. A major reason is that a lot of our code is direct model ports, and enforcing type hints would make it harder for contributors to port new models, since it would require more changes than just pasting in existing code and reparenting some classes.

We could consider doing something like this for internal classes and excluding model directories, though!

Yep, we can close as not planned, but in general we are trying to improve typing!