MySQL: Fix zero-value YEAR decoding, improve user docs around zero-value date/time types

[martykulma]

This started doc change and new test, but then @kay-kim uncovered a bug via manual testing! No we have a fix, which is included.

This PR fixes handling of zero-value YEAR

• snapshot decodes this as "0" instead of "0000"
• binlog decodes this as "1900" instead of "0000"

This also works around a mysql_common bug that treat zero-year binlog as 1900, which is an invalid year. It should be 0. See MySQL crazy set of rules for YEAR.

Additionally:

• adds some clarification to Materialize documentation around the integration with MySQL when using zero-value DATE, DATETIME, TIMESTAMP, and YEAR.
• expands the test coverage for YEAR to verify the documented behavior
• adjusts tests for DATE/DATETIME/TIMESTAMP to ensure snapshot and steady state paths are tested

[kay-kim]

Should this be 1900?

[martykulma]

Thanks for running it! It should definitely be 0, and the reason the automated test didn't catch it is because it ran so fast, everything was read via the snapshot. I modified the test and now see the failure.

text-columns-year.td:76:1: error: non-matching rows: expected:
[["1", "2024"], ["10", "2155"], ["2", "0"], ["3", "<null>"], ["4", "1901"], ["5", "2155"], ["6", "2025"], ["7", "0"], ["8", "<null>"], ["9", "1901"]]
got:
[["1", "2024"], ["10", "2155"], ["2", "0"], ["3", "<null>"], ["4", "1901"], ["5", "2155"], ["6", "2025"], ["7", "1900"], ["8", "<null>"], ["9", "1901"]]
Poor diff:
- 7 0
+ 7 1900