Define mypy_extensions.i16 in stubs

[JukkaL]

I forgot to add this when I added mypyc support for the i16 native integer type.

The mypy_extensions stubs are maintained here instead of typeshed.

This is a copy of the stubs for i32, with references to i32 replaced with i16.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[JelleZijlstra]

There are also mypy-extensions stubs in typeshed, should we drop those?

https://github.com/python/typeshed/tree/main/stubs/mypy-extensions

[AlexWaygood]

There are also mypy-extensions stubs in typeshed, should we drop those?

https://github.com/python/typeshed/tree/main/stubs/mypy-extensions

I was wondering this. The only reason I can see for them still being useful would be if somebody wanted to use some mypy-specific features, so started using mypy_extensions in their code, but still wanted basic typechecking to work well with other type checkers such as pyright. Feels a bit far-fetched, but maybe plausible?

The mypy_extensions stubs in typeshed are definitely in an unusual situation now, whatever the case.

[JukkaL]

The mypy-extensions stubs in typeshed are still useful for users of IDEs that perform on-the-fly type checking. In particular, they contain type aliases that allow using native integer types like i16 without generating errors, though mypy will perform additional checks not supported by IDEs. However, it would be much better to ship these "fallback" stubs with mypy-extensions.