Add Support for Import Aliasing

[sco1]

While #94 provided support for typing.overload, and #98 to add similar functionality for single dispatch, it came with a caveat that import aliasing is not supported.

For example, with this snippet:

from typing import overload as ovrld


@ovrld
def foo(a: int) -> int:
    ...

def foo(a):
    ...

The linter will not recognize the closing foo statement as part of the overload series:

$ flake8 ./asdf.py
./asdf.py:8:9: ANN001 Missing type annotation for function argument 'a'
./asdf.py:8:12: ANN201 Missing return type annotation for public function

The classification is currently made by explicitly matching "overload", either as it's own decorator (@overload) or as an attribute (@typing.overload). While functional, this approach is pretty brittle.

Even though we're lacking the ease of checking this in a linting environment that exists at runtime, we can likely still do a better job at identifying decorators in a more generic manner by adding an import visitor to the AST parsing to keep track of aliasing within the file being linted. This won't be perfect, but it can help broaden the current caveat.

[sco1]

Thinking about this some more recently, I think I'd rather implement this via a configuration option rather than coming up with some new scope tracking AST import walker that, even at its most clever, still has a lot of ways to be wrong at runtime.

For some prior art, I'm thinking something along the lines of how pep8-naming handles @classmethod and staticmethod decorators. This turns the error emitting for decorated functions into a generic True/False check without needing complicated AST machinery behind it.