Added comprehensive edge-case test coverage for DateFormatter

[InnaTarasyan]

This PR expands the existing DateFormatter tests to cover a wider range of real-world edge cases around dates, timezones, and relative formatting.

While the current tests cover the basic behavior, date and timezone handling can be tricky—especially around leap years, DST transitions, and large timezone offsets. These additional tests aim to make that behavior more explicit and guard against subtle regressions in the future.

What’s included

• Leap year scenarios (Feb 28 / Feb 29 / Mar 1)
• Daylight Saving Time transitions (spring forward & fall back)
• Timezones that do and don’t observe DST
• Conversions across different regions and large offsets
• Boundary cases (midnight, end of month, end of year)
• Relative date formatting for past and future dates
• A check to ensure the formatter doesn’t modify the original Carbon instance

The tests focus on correctness and stability rather than exact string output, to avoid being overly brittle.

Notes

• No production code changes — tests only
• Uses multiple timezones to reflect real usage
• Designed to catch edge cases that are easy to miss during refactors

Why

Date and timezone bugs tend to show up in edge cases rather than normal usage. Adding coverage here should make future changes to DateFormatter safer and easier to reason about.

[ssddanbrown]

Thanks for offering this PR @InnaTarasyan but at this stage these additions are really just testing the underlying library rather than our own logic. If there are app specific scenarios/regressions to cover then I'd be happy for those to be covered, but this seems to be adding tests for the sake of it.

Additionally I'm getting AI gen vibes, especially from the request issue in #5973, and I'm not keen on spending time reading/reviewing machine generated thoughts/reasoning/content.