Get datetime template values in the user-configured timezone

### Apache Airflow version

2.3.0 (latest released)

### What happened

One could expect by [the documentation about timezones](https://airflow.apache.org/docs/apache-airflow/stable/timezone.html), that Airflow will respect `default_timezone` (from airflow.cfg [core]) or a DAG's `timezone`, no matter how it stores timestamps internally (UTC).
But the [template variables](https://airflow.apache.org/docs/apache-airflow/stable/templates-ref.html#variables) don't do that, which could result unexpected results or unnecessarily complicated expressions should be used all over.

### What you think should happen instead

Please provide timezone aware template variables! A `tz` suffix/prefix could denote the timezone aware variants. For example: `data_interval_start` => `data_interval_start_tz`, `ds` => `ds_tz`, `logical_date` => `logical_date_tz`.

### How to reproduce

For example I use local timezone (CET/CEST) in all of my DAGs which is ahead of GMT (UTC) by +1 or +2 hours in the summer (DST). Nearly all tasks have date arguments, and some of them are running between 01:00 and 02:00. For example for `execution_date="2022-05-01T01:30:00+02:00"`, this would mean, that the date will be **2022-05-01** in the winter, and **2022-04-30** in the summer in UTC.

Of course I could work this around by using `logical_date.in_tz(dag.timezone).date()` in every template, instead of just `ds`, but it isn't a really nice solution. (As a matter of fact I have rather patched taskinstance.py to have timezone aware template vars.)

### Operating System

CentOS Stream 8

### Versions of Apache Airflow Providers

_No response_

### Deployment

Virtualenv installation

### Deployment details

_No response_

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] 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)

Start with the timezone documentation and templates reference, then inspect taskinstance.py, which the report identifies as the relevant customization point. Trace how default_timezone and a DAG's timezone reach template values, including DST cases. Done means timezone-aware template values are available without repeated in-template conversion and their behavior is covered by tests.

Written by the indexing model from the issue text.