Removing remaining parallel-build hazards in ecpg

The discussion around bug #15525 prompted me to go back and review
our previous go-round with parallelism issues in the ECPG build,
https://www.postgresql.org/message-id/flat/26240C1F-5AA0-41D6-B1F1-D336BFD14CEA%40logicalchaos.org

At that time we'd identified several maybe-issues with parallel
ECPG builds, which we solved with the big-hammer approach of
putting .NOTPARALLEL in ecpg/Makefile, mainly because there did
not seem to be any other way to work around a bug in gmake itself.
Later we made that workaround conditional on the specific gmake
version that had the bug ... but that means the other issues
come back to being live hazards, if you're using any gmake
version other than 3.82.

Reviewing that old thread, and looking again at the makefiles today,
I think the only remaining hazard is that preproc/Makefile does this:

../ecpglib/typename.o: ../ecpglib/typename.c
$(MAKE) -C $(dir $@) $(notdir $@)

which potentially conflicts with a make proceeding in parallel in
ecpglib. At the time, Peter had suggested that we dodge the problem
by having preproc symlink typename.c into its own directory and
build a second copy of typename.o. That file is small enough that
building it twice isn't much overhead; plus, this avoids the problem
that ecpglib has to be built with shared-library CFLAGS whereas
preproc would rather have a copy that isn't. So this seems like
a good solution.

However, trying to make it happen, I stumbled across the problem that
'#include "extern.h"' means something different in ecpglib than it
does in preproc, because those two directories both have files of that
name (as does pgtypeslib).

This seems to me like bad software design, so what I'd really rather
do about it is rename those three files to have distinct names.
But that'd be a noticeably more invasive patch than just hacking
CPPFLAGS while building typename.o (although getting the MSVC scripts
to do the latter might be hard). Any opinions about which to do?

(Note that these files aren't installed, so we aren't talking about
creating any user-visible API break from renaming.)

I'm also wondering whether to back-patch such a change. Since we've
not heard field complaints that match up to this problem, it may be
that it's unlikely enough that fixing it in HEAD is good enough.

regards, tom lane