Optimize functions returning a varlena buffer

[Algunenano]

LWGEOM_asBinary calls lwgeom_to_wkb which does the task to serialize the geometry in the WKB format and then, to be able to output it as a datum, it needs to allocate another buffer and copy all the information there.

I think this could benefit from a small change in lwgeom_to_wkb to return a Datum / varlena (or an equivalent liblwgeom type) directly. We already have SIZE_SET and SIZE_GET for gserialized operations and they could be reused here.

This would only make sense if there was a noticeable impact in performance, which is what I intend to investigate in this issue.

[Algunenano]

A similar thing happens in the functions that output from a stringbuffer (ST_AsText, ST_AsKML…): the string is generated in the stringbuffer, copied for output and then copied again in cstring_to_text (which also calls strlen on the whole string, even though we already know its size).

[Algunenano]

WIP with just ST_AsGeoJSON in ​https://github.com/postgis/postgis/pull/541

[Algunenano]

Full benchmarks in the PR (​https://github.com/postgis/postgis/pull/541) but the summary:

• ST_AsText, ST_AsGeoJSON, ST_AsTWKB: 1-3% improvement
• ST_AsBinary and variants: 6-22% improvement
• ST_AsX3D, ST_AsEncodedPolyline: 3% improvement
• ST_AsGML: 0-7% improvement
• ST_AsSVG: 3-7% improvement

[Raúl Marín <git@…>]

In 0696fa46/git:

Optimize varlena returning functions

Closes #4623
Closes ​https://github.com/postgis/postgis/pull/541

[Raúl Marín <git@…>]

In 591d0c6/git:

Revert incorrect "Optimize varlena returning functions"

This reverts commit 0696fa46699875fe43708d78602244fd6f257ee4.

I'm not sure what I did there, it seems like I pushed smaller commits
instead of a squashed one, and then did a revert that undid everything.

References #4623