Allow date formatting (:date) and time math on arbitrary variables (not just __from / __to)

<!-- Please only use this template for submitting feature requests --> **Why is this needed**: Grafana currently supports date formatting via the `:date` modifier (e.g. `${__from:date:YYYY-MM-DD}`), but this only works on **built-in time variables** like `__from`, `__to`, and `__now`. There is **no way to apply `:date` or perform time math** (e.g. `+1d`, `/d`, etc.) on **arbitrary variables**, even if those variables contain epoch timestamps or relative time strings such as `now`, `now-1d`, or `now/d`. This limits the ability to dynamically generate properly formatted time variable outside of the datepicker, especially for data sources like **Infinity**, and other **JSON**, or **REST API** integrations where users need to inject timestamps in ISO8601 or custom formats. **What would you like to be added**: If `myStart`/`myEnd` is a custom variable defined as `now-1d`/`now-7d`, Grafana **does not resolve** `:date` it simply inserts the raw string `now-1d`/`now-7d` and then resolves to `NaN`. This makes it impossible to generate formatted timestamps unless you rely on `__from` / `__to` (which are tied to the dashboard time picker). Desired behavior would allow arbitrary template variables to use the same date formatting syntax as Grafana’s built-in time variables if they contain epoch timestamps or relative time strings i.e. ```json { "from": "${myStart:date:YYYY-MM-DD}", "to": "${myEnd:date:YYYY-MM-DDTHH:mm:ssZ}" } ``` Examples: ```bash ${myVar:date:YYYY-MM-DD} ${myVar:date:iso} ${myVar:date:YYYY-MM-DDTHH:mm:ssZ} ${myVar + 1d:date:YYYY-MM-DD} # optional enhancement ``` - If `myVar` is `now/d`, it resolves to `2025-10-13T00:00:00Z` - If `myVar` is an epoch timestamp (e.g. `1728844800000`), it resolves correctly according to format - If `myVar` is another variable (e.g. `${start}`), Grafana resolves it recursively **Who is this feature for?** - Easily create custom variables for "last week," "same day last year," etc. - Provide parity between `__from` / `__to` ma…