feat: add converters for java.sql.Date, java.sql.Time, java.time.Instant and java.time.YearMonth

[CodeMan-cmd]

Purpose of the pull request

Related: #1017

Four types from the task in #1017 that are not on the list yet. I checked the current behaviour on main with a bean per type and all of them fail on read and on write:

write/read java.sql.Date -> ExcelWriteDataConvertException: Can not find 'Converter' support class Date.
write/read java.sql.Time -> ... support class Time.
write/read Instant       -> ... support class Instant.
write/read YearMonth     -> ... support class YearMonth.

java.sql.Date is worth calling out separately: it extends java.util.Date, which does have converters, but the converter map is keyed by the exact class, so a java.sql.Date field gets nothing.

What's changed?

The usual family (DATE, NUMBER, STRING) for each of the four types, following the shape of the families that are already here, with unit tests per family. All of them are registered in DefaultConverterLoader.

• converters/sqldate follows converters/date, using toLocalDate() as the intermediate and yyyy-MM-dd as the default format.
• converters/sqltime follows converters/localtime, using toLocalTime() and HH:mm:ss.
• converters/instant goes through java.util.Date / LocalDateTime, so use1904windowing keeps working. Excel has no time zone, so the value is read and written with the JVM default zone, the same way java.util.Date is handled.
• converters/yearmonth writes a month as a date cell of the first day of that month with a yyyy-MM number format, which keeps sorting and date arithmetic in the sheet working; the string family reads and writes yyyy-MM.

Tests: SqlDateDataTest, SqlTimeDataTest, InstantDataTest, YearMonthDataTest, each one a round trip over xlsx, xls and csv, with a plain field, a string field and a @DateTimeFormat field.

I kept the four families in one PR because they all register in DefaultConverterLoader and separate PRs would conflict there. Happy to split it into smaller PRs if you prefer.

Local verification with Temurin 1.8.0_472:

• ./mvnw clean package -B -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet -> 928 tests, 0 failures
• ./mvnw spotless:check -> Build success

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[skytin1004]

Thanks for working on these converters. I ran the full test suite locally with Java 11, and everything passed. I did notice two edge cases that do not seem to be covered yet.

YearMonth does not fall back to the default yyyy-MM format when DateTimeFormat is present but empty. In that case, reading 2020-01 fails, and writing can produce an empty value.

The new string converters also appear to ignore the locale configured in Fesod. For example, with French configured, a value such as 01 janvier 2020 cannot be parsed because the system locale is used instead.

Could you take a look at these cases and add tests for them?

[skytin1004]

Could we treat an empty format the same as a missing one here? DateTimeFormat defaults to an empty value, so reading 2020-01 currently uses an empty pattern and fails. The write path below has the same problem.

[skytin1004]

Could we use globalConfiguration.getLocale() here and in the other new string converters? With French configured, 01 janvier 2020 currently fails because the system locale is used instead.