Fix the representation of season in Biblatex date field.

[urlyy]

Fixes #12437

Description

When adding an entry like @Article{Article, date = {2025-21} }, the value 21 is interpreted as spring and added to the yeardivision entry field, rather than being treated as an out-of-range month and throwing an exception.

For reference:

Demonstration

Existing problems

• Should I use YearDivision or Season as the class name? The BibLaTeX documentation uses YearDivision, but it seems that YearDivision might also include some other values.
  
• Season does not require a shortName, is the getJabRefFormat method still necessary?

TODO

Since I am a beginner in bibliography management and not certain whether my approach is correct, I have only implemented it preliminarily. If you think it is acceptable, I will proceed to finish the following TODO items:

• The handling for the format 2002-21 has been implemented, but the handling for the format 2002-21/2002-23 has not yet been implemented.
  
• Remove the redundant parts in the Season class.
• Improve the basic functions of the Date class, such as toString, equals, and hashCode

Mandatory checks

• I own the copyright of the code submitted and I licence it under the MIT license
• Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[github-actions]

JUnit tests are failing. In the area "Some checks were not successful", locate "Tests / Unit tests (pull_request)" and click on "Details". This brings you to the test output.
You can then run these tests in IntelliJ to reproduce the failing tests locally. We offer a quick test running howto in the section Final build system checks in our setup guide.

[github-actions]

JUnit tests are failing. In the area "Some checks were not successful", locate "Tests / Unit tests (pull_request)" and click on "Details". This brings you to the test output.
You can then run these tests in IntelliJ to reproduce the failing tests locally. We offer a quick test running howto in the section Final build system checks in our setup guide.

[github-actions]

JUnit tests are failing. In the area "Some checks were not successful", locate "Tests / Unit tests (pull_request)" and click on "Details". This brings you to the test output.
You can then run these tests in IntelliJ to reproduce the failing tests locally. We offer a quick test running howto in the section Final build system checks in our setup guide.

[Siedlerchr]

Very good work! I would like to see some more tests, but otherwise on the first look it does a good first impression.

[koppor]

Some minor comments.

Please also add a CHANGELOG.md entry

[koppor]

Please use Optional.ofNullable

[koppor]

Why a different format then the others?

Isn't there a compact form (similar to DateTimeFormatter.ISO_DATE_TIME.format or other results here?)

Action point: Either use a compact form or add a Java comment that there is no compact form