tzdata-legacy should be included in distroless/static image

[jegorbunov]

Describe the bug
My Go application parses timezones provided by external sources.
It uses gcr.io/distroless/static:nonroot as the base image.

After updating to newer image versions (e.g. digest f9f84bd96843), the application started failing to resolve some timezones that previously worked. Investigation suggests this is related to the Debian 13 change that splits timezone data into tzdata and tzdata-legacy:
https://www.debian.org/releases/trixie/release-notes/issues.en.html#timezones-split-off-into-tzdata-legacy-package

It appears that legacy zones are no longer present in the image filesystem.

Is this expected behavior?
I believe this is not desirable for compatibility, and that tzdata-legacy should be included in new static images.

---

To Reproduce

Steps to reproduce the behavior:

1. Build/run a Go application that loads timezones via time.LoadLocation()
2. Use gcr.io/distroless/static:nonroot as the runtime base image
3. Attempt to load a legacy timezone (example: "Europe/Kiev")
4. Observe failure resolving the timezone in newer image digests (e.g. f9f84bd96843)

---

Expected behavior

Previously valid timezone identifiers should continue to resolve successfully.
The container image should include all timezone definitions necessary for backward compatibility, including those now provided by tzdata-legacy.

---

Console Output
(not applicable)

[loosebazooka]

Yeah that's not unreasonable. Feel free to add a pr or I'll get it to today/tomorrow.

[loosebazooka]

Also, we generally don't recommend using the non-debian version suffixed image references: gcr.io/distroless/static:nonroot for this exact reason. I would instead, for some stability, use gcr.io/distroless/static-debian12:nonroot or gcr.io/distroless/static-debian13:nonroot and update in a more controlled manner.