shared/calendarspec: fix normalization when DST is negative

shared/calendarspec: fix normalization when DST is negative

When trying to calculate the next firing of 'hourly', we'd lose the
tm_isdst value on the next iteration.

On most systems in Europe/Dublin it would cause a 100% cpu hang due to
timers restarting.

This happens in Europe/Dublin because Ireland defines the Irish Standard Time
as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight
saving.

Before this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
  Original form: hourly
Normalized form: *-*-* *:00:00
    Next elapse: Sat 2025-03-29 23:00:00 GMT
       (in UTC): Sat 2025-03-29 23:00:00 UTC
       From now: 13h ago
   Iteration #2: Sun 2025-03-30 00:00:00 GMT
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
   Iteration #3: Sun 2025-03-30 00:00:00 GMT  <-- note every next iteration having the same firing time
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
...

With this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
  Original form: hourly
Normalized form: *-*-* *:00:00
    Next elapse: Sat 2025-03-29 23:00:00 GMT
       (in UTC): Sat 2025-03-29 23:00:00 UTC
       From now: 13h ago
   Iteration #2: Sun 2025-03-30 00:00:00 GMT
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
   Iteration #3: Sun 2025-03-30 02:00:00 IST  <-- the expected 1 hour jump
       (in UTC): Sun 2025-03-30 01:00:00 UTC
       From now: 11h ago
...

This bug isn't reproduced on Debian and Ubuntu because they mitigate it by
using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would
cause pid1 to spin during DST transition.

This is how the affected tzdata looks like:
$ zdump -V -c 2024,2025 Europe/Dublin
Europe/Dublin  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0
Europe/Dublin  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0

Compare it to Europe/London:
$ zdump -V -c 2024,2025 Europe/London
Europe/London  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0
Europe/London  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0

Fixes #32039.