Make StringInfo available to frontend code.

Hi,

This patch, in a slightly rougher form, was submitted as part of [1],
but it seems worth bringing up separately, rather than just committing
hearing no objections.

From the commit message:

Make StringInfo available to frontend code.

There's plenty places in frontend code that could benefit from a
string buffer implementation. Some because it yields simpler and
faster code, and some others because of the desire to share code
between backend and frontend.

While there is a string buffer implementation available to frontend
code, libpq's PQExpBuffer, it is clunkier than stringinfo, it
introduces a libpq dependency, doesn't allow for sharing between
frontend and backend code, and has a higher API/ABI stability
requirement due to being exposed via libpq.

Therefore it seems best to just making StringInfo being usable by
frontend code. There's not much to do for that, except for rewriting
two subsequent elog/ereport calls into others types of error
reporting, and deciding on a maximum string length.

For the maximum string size I decided to privately define MaxAllocSize
to the same value as used in the backend. It seems likely that we'll
want to reconsider this for both backend and frontend code in the not
too far away future.

For now I've left stringinfo.h in lib/, rather than common/, to reduce
the likelihood of unnecessary breakage. We could alternatively decide
to provide a redirecting stringinfo.h in lib/, or just not provide
compatibility.

I'm still using stringinfo in the aforementioned thread, and I also want
to use it in a few more places. On the more ambitious side I really
would like to have a minimal version of elog.h available in the backend,
and that would really be a lot easier with stringinfo available.

I also would like to submit a few patches expanding stringinfo's
capabilities and performance, and it seems to me it'd be better to do so
after moving (lest they introduce new FE vs BE compat issues).

This allows us to remove compat.c hackery providing some stringinfo
functionality for pg_waldump (which now actually needs to pass in a
StringInfo...). I briefly played with converting more code in
pg_waldump.c than just that one call to StringInfo, but it seems that'd
be best done separately.

Comments?

Greetings,

Andres Freund

[1] https://postgr.es/m/20190920051857.2fhnvhvx4qdddviz@alap3.anarazel.de