### Apache Airflow version

2.1.3 (latest released)

### Operating System

Debian Buster

### Versions of Apache Airflow Providers

_No response_

### Deployment

Managed Services (Astronomer, Composer, MWAA etc.)

### Deployment details

Running `quay.io/astronomer/ap-airflow:2.1.3-buster` Docker image

### What happened

In the task attributes view of a BashOperator, the `template_ext` row doesn't show any value, while I would expect to see `('.sh', '.bash')`.

![image](https://user-images.githubusercontent.com/6249654/131467817-8620f68d-0f3d-491d-ad38-cbf5b91cdcb3.png)


### What you expected to happen

Expect to see correct `template_ext` value

### How to reproduce

Run a BashOperator and browse to Instance Details --> scroll down to `template_ext` row

### Anything else

Spent a little time trying to figure out what could be the reason, but haven't found the problem yet. Therefore created issue to track.

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

airflow/models/baseoperator.py
: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
        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