Resolve the S2 cell id to uint64_t like the other cell ids

[estebanzimanyi]

S2CellId is MobilityDB's typedef uint64 S2CellId, a 64-bit cell id exactly
like H3Index and Quadbin. The type recovery and the header-type pass list
H3Index and Quadbin as uint64 cell ids and leave S2CellId out, so the catalog
spells its slots in two ways neither sibling uses: a scalar carries the
platform canonical "unsigned long" (s2cell_in, ts2cell_start_value) and an
array keeps the opaque "S2CellId *" (s2cellset_values, ts2cell_values). The
shape pass reads the element of a written-back array against the by-value
scalars, so the S2CellId **values out-parameter of ts2cell_unnest is not a
parallel output array, and a binding hands the callee one element's storage
for the array it allocates.

S2CellId joins H3Index and Quadbin in both tables, and the 67 s2cell
functions read as the h3 and quadbin ones do: cType and canonical uint64_t.

Witness: the catalog derived from MobilityDB with the typed unnest functions
carries ts2cell_unnest with outputArrays [values], as th3index_unnest and
tquadbin_unnest do; without the entry its shape carries no outputArrays.
test_cell_id_canonical_normalized_uniform covers ts2cell_start_value,
ts2cell_end_value, s2cell_in and the values arrays of the three cell types.

Why: the network surface reads the s2cell functions as it reads the h3 and
quadbin ones. A uint64_t slot has no JSON decoder, so the exposable count
moves from 2506 to 2467 (s2cell 52 -> 13 exposable, the quadbin count). The
JSON integer that exposed them cannot carry an S2 cell id, whose face bits sit
above 2^61, beyond the 2^53 a JSON number holds exactly.