State each function's sqlfn as the one SQL name its signatures carry

[estebanzimanyi]

A function whose SQL signatures all carry one name takes that name as
its sqlfn, and the signatures carry no sqlName restating it
(parser/sqlfn.py state_deployed_sqlfn, run once the backing tags are
classified). A wrapper's @sqlfn names one member of the family it
serves: Set_in is tagged intset_in() and backs floatset_in, geomset_in
and fifteen more, while each one's CREATE FUNCTION deploys its own name.
A function whose signatures carry several names, such as the
eDwithin/aDwithin pair over one ea_* function, keeps the tag and each
signature its own name. A sqlfnBackingOnly record keeps its backing tag
beside its publicSqlName.

Why. A binding registers a function under its sqlfn. floatset_in was
stated as intset_in, tfloatinst_make as tint and tfloat_values as
getValues, which in SQL names the function returning the span set.

Measured. Over MobilityDB 72abdf86c2, 68 functions change their sqlfn
and the signature of each drops its sqlName, every one public: 52 text
readers and writers (floatset_in from intset_in, tfloat_in from
tint_in), 10 instant constructors (tfloatinst_make from tint), 3 value
sets (tfloat_values from getValues to valueSet), 2 point-to-geo casts
(tgeogpoint_to_tgeography from tgeometry to tgeography) and
contains_cbuffer_cbuffer (from contains to cbuffer_contains). Nothing
else in the catalog changes, the 70 backing records included, and the
portable parity report is byte for byte the same.

Witness. tests/test_sqlfn_deployed.py states the deployed name, keeps
the tag over several names, over a backing record and without
signatures, and over the catalog finds the per-type names and no
function whose signatures name one member other than its sqlfn; the
catalog tests fail on the catalog derived without this change. The
suite floor goes from 383 to 390.