Re: Cleaning up historical portability baggage

I have committed the first few:

* "Remove dead getrusage replacement code."
* "Remove dead handling for pre-POSIX sigwait()."
* "Remove dead getpwuid_r replacement code."

Here are some more, a couple of which I posted before but I've now
gone a bit further with them in terms of removing configure checks
etc:

* "Remove dlopen configure probe."
* "Remove configure probe and extra tests for getrlimit."
* "Remove configure probe for shm_open."
* "Remove configure probe for setsid."
* "Remove configure probes for readlink, and dead code and docs."
* "Remove configure probe for symlink, and dead code."
* "Remove configure probe for link."
* "Remove dead replacement code for clock_gettime()."
* "Remove configure probes for poll and poll.h."
* "Remove dead setenv, unsetenv replacement code."
* "Remove dead pread and pwrite replacement code."
* "Simplify replacement code for preadv and pwritev."
* "Remove --disable-thread-safety."

Some of these depend on SUSv2 options (not just "base"), but we
already do that (fsync, ...) and they're all features that are by now
ubiquitous, which means the fallback code is untested and the probes
are pointless.

<archeology-mode>I'd guess the last system we ran on that didn't have
symlinks would have been SVr3-based SCO, HP-UX, DG/UX etc from the
1980s, since they were invented in 4.2BSD in 1983 and adopted by SVr4
in 1988. The RLIMIT_OFILE stuff seems to be referring to 1BSD or 2BSD
on a PDP, whereas RLIMIT_NOFILE was already used in 4.3BSD in 1986,
which I'd have guessed would be the oldest OS POSTGRES ever actually
ran on, so that must have been cargo culting from something older?</>

The clock_gettime() one only becomes committable once prairiedog's
host switched to NetBSD, so that'll be committed at the same time as
the fdatasync one from a nearby thread.

The setenv/unsetenv one levels up to SUSv3 (= POSIX issue 6, 2001).
That'd be the first time we don't point at SUSv2 (= POSIX issue 5,
199x) to justify a change like this.

I expect there to be further clean-up after the removal of
--disable-thread-safety.