bg worker: patch 1 of 6 - permanent process

This patch turns the existing autovacuum launcher into an always running
process, partly called the coordinator. If autovacuum is disabled, the
coordinator process still gets started and keeps around, but it doesn't
dispatch vacuum jobs. The coordinator process now uses imessages to
communicate with background (autovacuum) workers and to trigger a vacuum
job. So please apply the imessages patches [1] before any of the bg
worker ones.

It also adds two new controlling GUCs: min_spare_background_workers and
max_spare_background_workers. The autovacuum_max_workers still serves as
a limit for the total amount of background/autovacuum workers. (It is
going to be renamed in step 4).

Interaction with the postmaster has changed a bit. If autovacuum is
disabled, the coordinator isn't started with
PMSIGNAL_START_AUTOVAC_LAUNCHER anymore, instead there is an
IMSGT_FORCE_VACUUM that any backend might want to send to the
coordinator to prevent data loss due to XID wrap around (see changes in
access/transam/varsup.c). The SIGUSR2 from postmaster to the coordinator
doesn't need to be multiplexed anymore, but is only sent to inform about
fork failures.

A note on the dependency on imessages: for just autovacuum, this message
passing infrastructure isn't absolutely necessary and could be removed.
However, for Postgres-R it turned out to be really helpful and I think
chances are good another user of this background worker infrastructure
would also want to transfer data of varying size to and from these workers.

Just as in the current version of Postgres, the background worker
terminates immediately after having performed a vacuum job.

Open issue: if the postmaster fails to fork a new background worker, the
coordinator still waits a whole second after receiving the SIGUSR2
notification signal from the postmaster. That might have been fine with
just autovacuum, but for other jobs, namely changeset application in
Postgres-R, that's not feasible.

[1] dynshmem and imessages patch
http://archives.postgresql.org/message-id/ab0cd52a64e788f4ecb4515d1e6e4691@localhost