**Apache Airflow version**: 2.1.2


**Kubernetes version (if you are using kubernetes)** (use `kubectl version`): 1.19.8

**Environment**:

- **Cloud provider or hardware configuration**:
- **OS** (e.g. from /etc/os-release): Amazon Linux EKS
- **Kernel** (e.g. `uname -a`): 
- **Install tools**: Helm (community chart)
- **Others**:

**What happened**:

With the addition of `__new__` to the `BaseOperatorMeta` class, this breaks our usage of operators that allow configuration through `__init_subclass__` arguments.

Relevant python bug: https://bugs.python.org/issue29581

**What you expected to happen**:

We should be able to use `__init_subclass__` in operators as we used to be able to. We relied on this behavior to customize some of our subclasses. This is working in 2.0.2 (though might exactly be considered a regression).

**How to reproduce it**:

This is a broken example

```py3
import datetime

from airflow import DAG
from airflow.operators.bash import BashOperator


class PrefixedBashOperator(BashOperator):
    def __init_subclass__(cls, command: str = None, **kwargs):
        if command is not None:
            cls._command = command

        super().__init_subclass__(**kwargs)

    def __init__(self, bash_command, **kwargs):
        super().__init__(bash_command=self._command + ' ' + bash_command, **kwargs)


class EchoOperator(PrefixedBashOperator, command='echo'):
    pass


with DAG(dag_id='foo', start_date=datetime.datetime(2021, 7, 1)) as dag:
    EchoOperator(task_id='foo', bash_command='-e "from airflow"', dag=dag)
```

This results in error:

```
TypeError: __new__() got an unexpected keyword argument 'command'
```

**Anything else we need to know**:

This example works. This shows that all that is needed to fix the issue is add `**kwargs` to `__new__`

```py3
import datetime
from abc import ABCMeta

from airflow import DAG
from airflow.models.baseoperator import BaseOperatorMeta
from airflow.operators.bash import BashOperator


class NewBaseOperatorMeta(BaseOperatorMeta):
    def __new__(cls, name, bases, namespace, **kwargs):
        new_cls = super(ABCMeta, cls).__new__(cls, name, bases, namespace, **kwargs)
        new_cls.__init__ = cls._apply_defaults(new_cls.__init__)  # type: ignore
        return new_cls


class PrefixedBashOperator(BashOperator, metaclass=NewBaseOperatorMeta):
    def __init_subclass__(cls, command: str = None, **kwargs):
        if command is not None:
            cls._command = command

        super().__init_subclass__(**kwargs)

    def __init__(self, bash_command, **kwargs):
        super().__init__(bash_command=self._command + ' ' + bash_command, **kwargs)


class EchoOperator(PrefixedBashOperator, command='echo'):
    pass


with DAG(dag_id='foo', start_date=datetime.datetime(2021, 7, 1)) as dag:
    EchoOperator(task_id='foo', bash_command='-e "from airflow"', dag=dag)
```


airflow/models/baseoperator.py
to your DAG's ``schedule_interval``. Daily jobs have their start_date
        some day at 00:00:00, hourly jobs have their start_date at 00:00
        of a specific hour. Note that Airflow simply looks at the latest
        ``execution_date`` and adds the ``schedule_interval`` to determine
        the next ``execution_date``. It is also very important
        to note that different tasks' dependencies
        need to line up in time. If task A depends on task B and their
        start_date are offset in a way that their execution_date don't line
        up, A's dependencies will never be met. If you are looking to delay
        a task, for example running a daily task at 2AM, look into the
        ``TimeSensor`` and ``TimeDeltaSensor``. We advise against using
        dynamic ``start_date`` and recommend using fixed ones. Read the
        FAQ entry about start_date for more information.
    :type start_date: datetime.datetime
    :param end_date: if specified, the scheduler won't go beyond this date
    :type end_date: datetime.datetime
    :param depends_on_past: when set to true, task instances will run
        sequentially and only if the previous instance has succeeded or has been skipped.
        The task instance for the start_date is allowed to run.
    :type depends_on_past: bool
    :param wait_for_downstream: when set to true, an instance of task
        X will wait for tasks immediately downstream of the previous instance
        of task X to finish successfully or be skipped before it runs. This is useful if the
        different instances of a task X alter the same asset, and this asset
        is used by tasks downstream of task X. Note that depends_on_past
        is forced to True wherever wait_for_downstream is used. Also note that
        only tasks *immediately* downstream of the previous task instance are waited
        for; the statuses of any tasks further downstream are ignored.
    :type wait_for_downstream: bool
    :param dag: a reference to the dag the task is attached to (if any)