Support STRING_TYPE_INFO when deserializing types (#65)

Any query result containing a VARCHAR column with an explicit collation
failed to render, replacing the whole result with "unsupported type info:
3". Selecting only non-collated columns worked, so ordinary `SELECT *` on
a schema using case-insensitive text columns was unusable.

readTypeInfo() handled ExtraTypeInfo tags 1, 2, 4, 5, 6, and 9, but not 3
(STRING_TYPE_INFO), which DuckDB attaches to any string type carrying a
collation. The default branch then threw. This is result type metadata, so
it failed even for empty results.

Read tag 3 as a StringTypeInfo, taking the collation from property 200.
DuckDB writes that property with a default, omitting it when the collation
is empty, so read it with a default of '' rather than requiring it.

Nothing downstream needs the collation: duckDBTypeFromTypeIdAndInfo() reads
only the alias for VARCHAR, and value conversion doesn't consult type info
for strings. So a collated column now renders as a plain VARCHAR, matching
what the CLI shows. The collation is kept in the model for fidelity.

Verified against a local UI server on 1.5.5, for the empty and non-empty
cases, for `COLLATE C` and `CAST(name AS VARCHAR)` (neither of which drops
the collation), and for collated VARCHAR nested in LIST and STRUCT.

Fixes duckdb/duckdb-ui#241

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>