feat: honor wildcard custom converters when reading

[BigDataDZ]

Purpose of the pull request

Custom converters registered with supportExcelTypeKey() == null (the wildcard contract: "matches
every cell data type") never applied on the read path: the built-in concrete-key converter silently
took over, or reading failed with Converter not found. With this change, a single
registerConverter(...) call works for reading exactly as it already does for writing.

Closed: #1085

What's changed?

AbstractReadHolder now routes custom converter registration through registerCustomConverter,
which — when supportExcelTypeKey() is null — additionally registers the converter under every
concrete CellDataTypeEnum key (all except EMPTY, which is filtered before lookup).

Read lookups (ConverterUtils#convertToJavaObject, ConverterUtils#convertToStringMap) use the
concrete cell type as key, so a wildcard registration at (JavaType, null) never matched: e.g. a
wildcard Boolean converter reading a "yes" cell produced false via the built-in
BooleanStringConverter (Boolean.valueOf("yes")), with no warning. This is the read-path twin of
#1045/#1056 (write/CSV flavor, addressed by PR #1069) and mirrors that PR's registration-expansion
approach, expanded to all concrete types because read lookups can arrive with any cell type.

Lookup code is untouched. Explicit-key registrations keep their priority semantics, and users
without wildcard custom converters are unaffected.

New WildcardConverterReadTest (round-trip): the wildcard-read case fails on current main
("yes" read as false) and passes with this change; the explicit STRING-key case is a
regression guard. Full fesod-sheet suite: 920/920 green.

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]

Hi @BigDataDZ,
I tried registering a STRING converter first and a wildcard converter second. Before this change, the STRING converter handled string cells. With this change, the wildcard converter handles them instead.
Is this change intentional? If not, could you keep the STRING converter handling these cells and add a test for this registration order?