date.truncate() should be timezone-awared

__Proposal:__
if you use the truncate-function for starting or stopping ranges on day- or month-base, one should be able to configure this to be timezone-awared.

__Current behavior:__
If you use something like `date.truncate(t: now(), unit: 1d)`, the result is something like 2022-04-28T00:00:00Z.
If this value is used as a time range for e.g. aggregateWindow() or range(), which are timezone-awared, the result consists of an additional window.
E.G.
`option location = timezone.location(name: "Europe/Berlin")`
`from(...)`
`|> range(start: experimental.subDuration(d: 7d, from: date.truncate(t: now(), unit: 1d)), stop: date.truncate(t: now(), unit: 1d))`
`.`
`.`
`|> aggregateWindow(every: 1d, fn: mean)`

Assuming now() is "2022-04-28T10:30:00Z" (local "2022-04-28T12:30:00CEST"), the range should be from "2022-04-21T00:00:00CEST" to "2022-04-28T00:00:00CEST", but is actually "2022-04-21T02:00:00CEST" to "2022-04-28T02:00:00CEST".
This results in a too short first day and an additional window today till 2:00 o'clock with the wrong aggregation of the results...

__Desired behavior:__
Assuming now() is "2022-04-28T10:30:00Z" I wish to have "2022-04-27T22:00:00Z" (local "2022-04-28T00:00:00CEST") as a result of `date.truncate(t: now(), unit: 1d)`

__Alternatives considered:__
--
__Use case:__
I have many graphs that are based on a series of pre-calculated daily values and live-calculated values on the current day for better performance. You can think of this on a monthly pattern as well...
The daily pre-calculated values are calculated on the local timezone daybreak, so the graph should be use the pre-calculated values till the very beginning of today and the live-calculated values should start immediately after this.
With the given example it is not possible to distinguish this point in time and I don't know about another way...

Start by tracing the date.truncate() entry point and its interaction with the timezone behavior described for range() and aggregateWindow(). Done means day- and month-based truncation can produce the requested local-time boundary, including the Europe/Berlin example, without the extra window.

Written by the indexing model from the issue text.