### 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
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)
    :type dag: airflow.models.DAG
    :param priority_weight: priority weight of this task against other task.
        This allows the executor to trigger higher priority tasks before
        others when things get backed up. Set priority_weight as a higher
        number for more important tasks.
    :type priority_weight: int