date: reject a date string with two timezone abbreviations

[mistaste]

Summary

Fixes #12875.

date -d "EST EST" was accepted and produced a date, while GNU date rejects it:

$ date -d "EST EST"           # uutils (before): Sun Jun 14 01:00:00 AM EDT 2026
$ gnudate -d "EST EST"        # GNU: invalid date 'EST EST'

Cause

try_parse_with_abbreviation strips a trailing timezone abbreviation and parses
the remainder. For "EST EST" the remainder is the bare abbreviation "EST",
which parse_datetime resolves to "now", so the whole string was wrongly accepted.

Change

• Factor the abbreviation lookup into resolve_tz_abbreviation.
• After stripping the trailing abbreviation, bail out if what remains is itself a
  bare timezone abbreviation. These double-timezone inputs then fall through to the
  standard parser, which already rejects them — matching GNU.

Single and bare abbreviations are unaffected:

$ date -u -d "EST EST"                 # exit 1: invalid date 'EST EST'
$ date -u -d "EST PST"                 # exit 1: invalid date 'EST PST'
$ date -u -d "2024-01-15 10:30 EST"    # 2024-01-15 15:30:00 UTC
$ date -u -d "EST"                     # now, in EST

Checks

• New regression test test_date_double_timezone_is_invalid; all test_date_tz_abbreviation_* tests still pass (9/9).
• cargo fmt clean, cargo clippy -p uu_date --all-targets clean.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/tail-n0f (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/basenc/bounded-memory is now being skipped but was previously passing.
Note: The gnu test tests/env/env-signal-handler was skipped on 'main' but is now failing.

[cakebaker]

Thanks for your PR!