[estebanzimanyi]

h3indexset is generated from the catalog's MeosType enum (T_H3INDEXSET) with the other set types:
tools/codegen_duck_udfs.py lists h3index in BASE_ORDER, beside quadbin and s2cell, with
H3indexTypes::h3index() as its element type, so SetTypes::h3indexset() registers the type, its
casts to and from VARCHAR, set(h3index) and set(h3index[]), and the generic set surface;
H3indexTypes declares the cell and the temporal cell, h3index and th3index. The registrations the catalog states over it
gain asText, getValues and the two hexadecimal WKB readers, and the H3 prefilter shapes
(geoToH3IndexSet, eEqual(h3indexset, th3index)) name the generated type.

Witness: on main SELECT setUnionAgg(v)::VARCHAR FROM (VALUES ('8a2a1072b59ffff'::h3index), ('8a2a1072b597fff'::h3index)) t(v) answers the raw bytes of the set, \xE0\x01\x00\x00ED...,
DuckDB's cast of a BLOB, where MobilityDB answers {"8a2a1072b597fff", "8a2a1072b59ffff"}; here
MobilityDuck answers MobilityDB's text.

Measured: over the catalog at MobilityDB f058a27e4a, the pin, the unchanged generator reproduces
the committed surface with no difference; the changed one registers 8363 functions, types and
casts against 8359: the type and four functions over h3indexset added, and the generated
set(h3index) left to the one SetTypes registers for every set type.
test/sql/th3index.test states an h3indexset read as text, through asText, from getValues and
from setUnionAgg against the text MobilityDB answers for the same values.

Why: an h3indexset was the one set type registered by hand, without the cast to VARCHAR every
generated set type takes, so DuckDB showed it as its bytes wherever a VARCHAR is wanted.