Supporting attrs extensions with different default arguments for decorators.

attrs' decorators can (and sometimes should) be wrapped, to create custom decorators. Using a "fake plugin", the custom decorators can be added to the maker lists and thus receive the special attrs treatment from mypy.
However, currently, mypy's attrs plugin has the default values of the arguments of attrs' decorators hardcoded. This means that it does not detect when the custom decorators define different default values, and thus raises (false positive) errors on some cases.

Here is an example for such a case:

import attr
from typing import Any

def my_attr_s(cls, kw_only: bool = True) -> Any:  # Added to attr_class_makers using "fake plugin".
    return attr.s(kw_only=kw_only)(cls)

def my_attr_ib(**kwargs) -> Any:  # Added to attr_attrib_makers using "fake plugin".
    return attr.ib(**kwargs)

@my_attr_s
class A:
    optional: str = my_attr_ib(default="This attrib is not required now.")

@my_attr_s
class B(A):
    required: str = my_attr_ib()

When type-checking this file, mypy gives the following error:

16: error: Non-default attributes not allowed after default attributes.

This error should actually not be emitted, because as opposed to what would happen if we we decorate A and B with attr.s, there is no problem here, because here we have kw_only set to True (by default, and nothing else was passed), so the order of the attributes is actually valid.

If mypy would take the decorator's arguments' default values for arguments that were not passed, it could avoid such false positives.
I would like to submit a PR which fixes this.

Start by reproducing the supplied example with mypy's attrs plugin and the fake-plugin maker lists, especially attr_class_makers and attr_attrib_makers. Trace how omitted decorator arguments are handled. Done means custom decorator defaults are respected and the false-positive non-default attribute error is no longer emitted.