Re: Rethinking -L switch handling and construction of LDFLAGS

So here's a draft patch for this. It fixes the originally complained-of
issue about --with-libxml breaking the build on Macs. I've not tested
it very far beyond that plus a sanity cross-check on Linux, but I doubt
there's any point in further manual testing; we might as well just
throw it at the buildfarm.

I'm pretty happy with the way this turned out. It's not a complicated
change, and we're no longer breaking our own rules about how to manage
LDFLAGS adjustments.

Some notes:

* I ended up adding not only LDFLAGS_INTERNAL and SHLIB_LINK_INTERNAL,
but also PG_LIBS_INTERNAL. As things stood, the only uses of PG_LIBS
were for within-tree library references, so that it was fine that the
make rule that uses this variable put it before LDFLAGS. But if anyone
ever tried to use PG_LIBS for the seemingly obvious purpose of referencing
an external library, we'd be right back in hazard land. So that variable
needs to be split as well.

* I documented SHLIB_LINK_INTERNAL and PG_LIBS_INTERNAL in the comments
in pgxs.mk, but not in the user-facing documentation about using PGXS.
This is on the theory that only within-tree modules need either of those
variables, so users don't need them. I could be convinced otherwise,
though.

* Some of these changes aren't really essential, eg the change in
hstore_plperl/Makefile to use SHLIB_LINK_INTERNAL instead of SHLIB_LINK;
since there's no -L switch there, it'd work either way. But I thought
it best to maintain a consistent rule of using the _INTERNAL variable
for within-tree references.

* The change to STD_LDFLAGS in src/common/Makefile is because I noticed
that "pg_config --ldflags" has been printing "-L../../../src/common",
which it surely should not. Apparently we forgot to fix this rule when
we rearranged things to create src/common/. I'm tempted to make the
rule be

STD_LDFLAGS := $(filter-out $(LDFLAGS_INTERNAL),$(LDFLAGS))

in hopes of preventing a repetition of such silliness, but desisted
for the moment, because I'm not quite sure if this is a good idea,
or if it risks taking too much out. Anybody have an opinion about it?

regards, tom lane