libpq hooks patch v2

Here is an updated version of the 'libpq-side' changes required to
implement the libpqtypes proposal. This fixes the complaints Tom had,
particularly the process lock on the various functions that kept
private state linked up with the PGconn. We did this in a slightly
different way than Tom proposed...by keeping a void* in the
PGobjectHooks struct.

While we think this approach works, it is possibly to complicated for
what it does. This could possibly be said of the hooking approach in
general. We can't think of a good use case for other applications to
use the hooks. The hook system feels awkward on both sides (in libpq,
and libpqtypes). Why keep code abstract when it only has one real
purpose?

Possibly, a better approach than the hooking system is a wholesale
wrapping of libpq, introducing a extended PGconn struct (PQTconn for
example), with the private state stored in there and passed to all the
libpqtypes functions. This would mean a complete new API, something
we wanted to avoid. We see our proposal as a natural extension of
libpq, library code, not application code. This difference of
perception is perhaps what the impasse is.

We think our other proposed strategy is better...namely to load the
libpqtypes functionality with dlopen and keep 'stub' functions inside
libpq which raise a runtime error if the library is not loaded. This
resolves a major raised complaint, library size, and allows the stub
functions to better handle certain things that should be in libpq, for
example error handling.

We understand this raises the bar for libpqtypes in terms of
consensus...since it pushes certain aspects of libpqtypes into libpq,
the whole thing has to be 'signed off' on, and there has naturally
been a certain amount of resistance so far. At this point, function
stubs (PQparamExec and friends) are all we are proposing to add to
libpq. The remainder of the code can exist in core, pgfoundry, etc.
This is much more direct and useful to libpq developers than a
abstract hooking interface.

merlin