Handle duplicate X-WR-TIMEZONE values

[legalverb]

Fixes #25.

Summary

• Normalize duplicate calendar-provided X-WR-TIMEZONE values before resolving them with zoneinfo.
• Use the duplicate value when all X-WR-TIMEZONE entries agree.
• Treat conflicting duplicate values as ambiguous and leave the calendar unchanged instead of raising an attribute/type error.
• Add regression coverage for matching and conflicting duplicate timezone metadata.

Behavior

The issue did not include the original ICS file, so this keeps the behavior conservative:

• repeated identical calendar-level time zones are safe to use;
• conflicting calendar-level time zones are ignored because the correct conversion target is ambiguous.

Tests

• . .venv/bin/activate && pytest test/test_convert_examples.py -q
• . .venv/bin/activate && pytest -q
• sh test/test_code_quality.sh
• git diff --check

Note: CONTRIBUTING.md asks for a changelog entry except for trivial changes, but I could not find a changelog/news file in this repository to update.

[niccokunzmann]

Thank you for your PR!
I think, the changelog is in the README.

It would be nice if you could also edit the contributing file.

[niccokunzmann]

Hi, the tests have a calendars directory. Please put all calendars in there.

[legalverb]

Thanks for the review. I moved the duplicate X-WR-TIMEZONE test calendars into test/calendars and rebased the branch on current main, so the PR is mergeable again.

Local verification:

• git diff --check: passed
• Tried running the focused pytest targets, but this local venv is currently hanging while importing pytest/icalendar before test output. The change itself now uses the existing calendars fixture and fixture directory as requested.

[niccokunzmann]

Thanks! Perfect! Merging....