splitting *_desc routines

So Andres Freund floated a proposal to create an xlogdump sort of tool,
in core, and posted a patch.

One advantage of having xlogdump in core is that we can have buildfarm
test that part of the Xlog code, which currently sees no testing at all.
In fact we could use it as a testbed for XLog in general, say by having
it run during "make installcheck" or some such.

I looked at Andres' patch and the general idea is rather horrible: it
links all backend files into the output executable. This is so that the
*_desc functions can be used from their respective object files, which
obviously have a lot of requirements for backend infrastructure.

However, after looking at the _desc routines themselves, they turn out
to be quite light on requirements: the only thing they really care about
is having a StringInfo around. (There are also two of them that call
relpathperm(), but I think that's easily fixable.)

(There is also a bug of sorts in gin_desc, which calls elog(PANIC) when
finding a record it doesn't know about; but all other routines simply
call appendStringInfo("unkwown") instead, so I think the right fix here
is to change gin to do the same -- and this should be backpatched all the
way back.)

So it is my intention to split out the desc() functions out of their
current files, into their own file, allowing xlogdump to link against
that and not be forced to link the rest of the backend.

To solve the stringinfo problem, we would provide a separate
implementation of it, one that doesn't depend on palloc and elog.
Initially I would just put it in src/bin/xlogdump, but if people think
we could use it elsewhere, we could do that too. Alternatively we could
use a shim layer on top of PQExpBuffer. In fact, we could change the
desc() routines, so that #ifdef FRONTEND they use PQExpBuffer, and
StringInfo otherwise.

One further decision here is whether the various desc() routines should
be each in its own file, or have them all in a single file. If we use a
single file (which is what I'm inclined to do) we'd need to rename some
static routines that have the same name, such as "out_target"; but this
seems a rather trivial exercise.

Thoughts?

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>