Report a @csqlfn naming a wrapper over another container

[estebanzimanyi]

A MEOS function's name ends in the container it takes, and its @csqlfn names
the PG wrapper it corresponds to. Where the two disagree about the container,
every existing check still passes: the wrapper exists, nothing is unreachable,
and the arity matches. What the catalog then derives is the SQL surface of a
different overload, so lint_container_family_csqlfn reports the disagreement
beside the ever/always, positional and case lints run over the same map.

Reading the suffixes literally reports the tree rather than a defect. A
concrete function name over a generic wrapper is how the value surface is
written throughout — adjacent_span_timestamptz names Adjacent_span_value
because one wrapper serves every base type — and forty names disagree that
way. Both sides are therefore read as a container family, mapping tstzset to
set and timestamptz to value, which leaves the seven that named a wrapper over
another container and which MobilityDB now corrects.

The lint reports none against a MobilityDB tree carrying that correction. Its
test states the case it must catch and four it must not, and neutering the
comparison fails the first while leaving the others passing, so the suite
discriminates the lint rather than agreeing with it either way.