fix: remove Literal.toPython date conversion for gYear/gYearMonth

[lu-pl]

Summary of changes

Issue #3078 reports, that rdflib.Literal.toPython-casting of xsd:gYear and xsd:gYearMonth to datetime objects should not be possible, as there is no appropriate Python equivalence for those types.

The current implementation casts xsd:gYear and xsd:gYearMonth to datetime objects assuming January 1st for xsd:gYear and the 1st day of the given month for xsd:gYearMonth. This is plain wrong.

The change removes datetime casting for xsd:gYear and xsd:gYearMonth for rdflib.Literal.toPython and adapts the rdflib.Literal tests accordingly.

Note that validation of xsd:gYear and xsd:gYearMonth is lost as a result, but could be easily implemented using regex checks. As I understand it, XSD types without an entry in the rdflib.term.XSDToPython mapping are never typed-checked though; at least for xsd:gYear and xsd:gYearMonth the xsd-type checks ran as part of rdflib.xsd_datetime.parse_xsd_gyear and rdflib.xsd_datetime.parse_xsd_gyearmonth.

Checklist

• Checked that there aren't other open pull requests for
  the same change.
• Checked that all tests and type checking passes.
• If the change adds new features or changes the RDFLib public API:
  • Created an issue to discuss the change and get in-principle agreement.
  • [] Considered adding an example in ./examples.
• If the change has a potential impact on users of this project:
  • Added or updated tests that fail without the change.
  • Updated relevant documentation to avoid inaccuracies.
  • Considered adding additional documentation.
• Considered granting push permissions to the PR branch,
  so maintainers can fix minor issues and keep your PR up to date.

Note: I looked through the docs and couldn't find a place where xsd:gYear or xsd:gYearMonth casting was mentioned (apart from the generated references).

[lu-pl]

I set this to be ready for review, I don't know why the pipeline fails though.