Fix false positives in abstract methods

[jsh9]

Partially tackles #31

[ghjklw]

You could also use __isabstractmethod__ here (https://docs.python.org/3/library/abc.html#abc.abstractmethod), which might be slightly more robust in case another decorator has been used (e..g @abstractproperty, even though it's now deprecated)

[jsh9]

You actually touched on an interesting implementation detail of pydoclint.

Pydoclint performs static syntax analysis using Python's ast module. "Static" means that the Python code is not actually run when ast parses it.

For example, when ast parses this:

@abstractmethod
def something(self, arg):
    pass

It does not actually know that it is an abstract method. It only knows that the method something() has a decorator called "abstractmethod".

If you attempt to do this:

staticmethod = classmethod

@staticmethod
def something(self, arg):
    pass

ast will only know that the method something() has a decorator called "staticmethod".

By now you must have realized that there is a type of potential edge cases: if people do hello = staticmethod, world = abstractmethod, etc., pydoclint will get confused and throw false positive violations.

But in reality, very few people do that. (Would you?)

To be able to understand that "hello" means "staticmethod" in the code, we'd need to use Python's official inspect module. I chose not to, because using inspect to parse source code is much slower than using ast. (This is not difficult to understand: with inspect, we need to first get the source code running.)

Darglint uses inspect (see code examples here and here). I suspect this is why darglint is very slow.

What I plan to do is to summarize what I said above into a disclaimer section in pydoclint's documentation, so that users know what pydoclint is not designed to handle.