State the byte codec of each type beside its wire encodings

[estebanzimanyi]

typeEncodings gives each type, under bytes, the reader and the writer of its WKB bytes: a
reader T *f(const uint8_t *wkb, size_t size) and a writer
uint8_t *f(const T *, uint8_t variant, size_t *size_out), recognised by shape, the generic
_from_wkb and _as_wkb preferred as the wire codecs prefer theirs. The bytes are
no wire string, so they add no entry to encodings, which keeps the string forms a network
generator serves. A binding that holds values in process, as the JVM engines do, reads the
codec there instead of naming it itself.

Witness. test_byte_codec_beside_the_wire_encodings states the Temporal pair, leaves the
encodings at mfjson and text, and states no codec for a type with a writer and no reader.

Measured. Over the headers of MobilityDB 3f9ee86639, twelve types carry the entry: Temporal,
Set, Span, SpanSet, STBox, TBox, Cbuffer, Npoint, Pose, PoseChain, Raquet and Raster. The
catalog is otherwise identical to the one derived without the change. The suite runs its 37
test files, all passing.

Why. The Spark generator names the WKB functions in a table of its own and the Flink
generator finds only the hex codec here, so the two engines carry values in two forms;
stated once in the catalog, both take the same codec from it.