**Description**
The `airflow.models.baseoperator.chain()` is a very useful and convenient way to add sequential task dependencies in DAGs.  This function has [recently been updated](https://github.com/apache/airflow/issues/16635) to support `BaseOperator` and `XComArgs` but should also be able to support `Labels` as well.

**Use case / motivation**
Users who create tasks via the `@task` decorator will not be able to use the `chain()` function to apply sequential dependencies that do not share an `XComArg` implicit dependency with a `Label`.  This use case can occur when attempting to chain multiple branch labels and the next sequential task.

With the new update (yet to be released), users will receive the following exception when attempting to chain an `XComArg` and `Label`:

```bash
TypeError: Chain not supported between instances of <class 'airflow.utils.edgemodifier.EdgeModifier'> and <class 'airflow.models.xcom_arg.XComArg'>
```


**Are you willing to submit a PR?**
Absolutely. 🚀 

**Related Issues**
None

airflow/models/baseoperator.py
which ultimately becomes a node in DAG objects. Task dependencies should
    be set by using the set_upstream and/or set_downstream methods.
    :param task_id: a unique, meaningful id for the task
    :type task_id: str
    :param owner: the owner of the task, using the unix username is recommended
    :type owner: str
    :param email: the 'to' email address(es) used in email alerts. This can be a
        single email or multiple ones. Multiple addresses can be specified as a
        comma or semi-colon separated string or by passing a list of strings.
    :type email: str or list[str]
    :param email_on_retry: Indicates whether email alerts should be sent when a
        task is retried
    :type email_on_retry: bool
    :param email_on_failure: Indicates whether email alerts should be sent when
        a task failed
    :type email_on_failure: bool
    :param retries: the number of retries that should be performed before
        failing the task
    :type retries: int
    :param retry_delay: delay between retries
    :type retry_delay: datetime.timedelta
    :param retry_exponential_backoff: allow progressive longer waits between
        retries by using exponential backoff algorithm on retry delay (delay
        will be converted into seconds)
    :type retry_exponential_backoff: bool
    :param max_retry_delay: maximum delay interval between retries
    :type max_retry_delay: datetime.timedelta
    :param start_date: The ``start_date`` for the task, determines
        the ``execution_date`` for the first task instance. The best practice
        is to have the start_date rounded