Simplify multixact freezing a bit

Testing for abortedness of a multixact member that's being frozen is
unnecessary: we only need to know whether the transaction is still in
progress or committed to determine whether it must be kept or not.  This
let us simplify the code a bit and avoid a useless TransactionIdDidAbort
test.

Suggested by Andres Freund awhile back.
Avoid uselessly looking up old LOCK_ONLY multixacts

Commit 0ac5ad5134f2 removed an optimization in multixact.c that skipped
fetching members of MultiXactId that were older than our
OldestVisibleMXactId value.  The reason this was removed is that it is
possible for multixacts that contain updates to be older than that
value.  However, if the caller is certain that the multi does not
contain an update (because the infomask bits say so), it can pass this
info down to GetMultiXactIdMembers, enabling it to use the old
optimization.

Pointed out by Andres Freund in 20131121200517.GM7240@alap2.anarazel.de
pg_upgrade:  improve C comment wording
doc: Clean up some recently added PL/pgSQL documentation

- Capitalize titles consistently.
- Fix some grammar.
- Group "Obtaining Information About an Error" under "Trapping Errors",
  but make "Obtaining the Call Stack Context Information" its own
  section, since it's not about errors.
Fix mishandling of background worker PGPROCs in EXEC_BACKEND builds.

InitProcess() relies on IsBackgroundWorker to decide whether the PGPROC
for a new backend should be taken from ProcGlobal's freeProcs or from
bgworkerFreeProcs.  In EXEC_BACKEND builds, InitProcess() is called
sooner than in non-EXEC_BACKEND builds, and IsBackgroundWorker wasn't
getting initialized soon enough.

Report by Noah Misch.  Diagnosis and fix by me.
pgbench: Allow \setrandom to generate Gaussian/exponential distributions.

Mitsumasa KONDO and Fabien COELHO, with further wordsmithing by me.
Avoid wholesale autovacuuming when autovacuum is nominally off.

When autovacuum is nominally off, we will still launch autovac workers
to vacuum tables that are at risk of XID wraparound.  But after we'd done
that, an autovac worker would proceed to autovacuum every table in the
targeted database, if they meet the usual thresholds for autovacuuming.
This is at best pretty unexpected; at worst it delays response to the
wraparound threat.  Fix it so that if autovacuum is nominally off, we
*only* do forced vacuums and not any other work.

Per gripe from Andrey Zhidenkov.  This has been like this all along,
so back-patch to all supported branches.