Improve .pyi files support

[sobolevn]

Currently, we have a lot of rules that are not very aligned with .pyi files.

Here are some of them:

• ... usage as a placeholder
• complexity rules like number of arguments, methods, etc (we cannot control things like it in annotations)

And probably others as well.

What we need to do here is ignoring this violations when filename has .pyi extension.
And better docs about this case.

Related: https://github.com/dry-python/returns/blob/master/setup.cfg#L50

[sobolevn]

Can be also tested on:

• https://github.com/typeddjango/django-stubs
• https://github.com/typeddjango/djangorestframework-stubs

[sobolevn]

We should also allow almost any names in .pyi files. We cannot control it either.

[sobolevn]

Also ignoring:

• WPS605, because methods can have 0 arguments in stubs
• WPS604, because all magic methods can be used in stubs
• WPS602, because @staticmethod can be used in stubs
• WPS600, because classes can subtype builtins in stubs
• WPS431, because there can be nested classes
• WPS428, because we use ... in stubs
• WPS412, because __init__.py can have logic
• WPS410, because we should allow different metadata variables
• WPS113, because mypy requires as imports for pubic API

Complexity rules (I still need to look through all of them):

• WPS235, because we cannot control the number of imports
• WPS215, because we cannot control the number of base classes

We also need a --external-stubs config flag to enable this mode.
Otherwise, we are still writing our own stubs. That have a limited set of silenced violations.

[sobolevn]

This is way too big for 0.14.

[maltevesper]

WPS211 is another complexity rule to consider for ignoring, It should already trigger on the actual implementation in the .py file.

Would it make sense to ignore WPS211 (too many args) and WPS428 (Ellipsis as unused code) on @overload stubs in .py files too?
The logic for WPS211 is that it is already caught in the actual implementation, warning in other places requires cluttering #noqa comments through the file if one has a valid exception.