Update CREATE FUNCTION documentation about argument names.

The 9.2 patch that added argument name support in SQL-language functions
missed updating a parenthetical comment about that in the CREATE FUNCTION
reference page.  Noted by Erwin Brandstetter.
Make pg_upgrade's test script attempt to select a non-conflicting port.

Previously, the port number used in this test script was hard-wired at
pg_upgrade's default of 50432; which is not so great because parallel build
runs might conflict.  Commit 3d53173e20d151341f894f79d556768c845ba3e4
removed this setting for the postmasters started by the script proper
(not by pg_upgrade), which didn't do anything to fix that problem and also
guaranteed a failure if there was a live postmaster at the build's default
port number.  Instead, select a non-conflicting temporary port number in
the same way that pg_regress.c does.  (Its method isn't entirely
bulletproof, but given the lack of complaints I'm not going to worry
about that today.)

In passing, unset MAKEFLAGS and MAKELEVEL to avoid problems with the
script's internal invocations of make, for the same reason pg_regress.c
does: it could cause problems in a parallel make.
Fix buildfarm incompatibility in updated pg_upgrade test script.

Looks like some versions of the buildfarm script try to set the port via
--port in $EXTRA_REGRESS_OPTS.  Override that ...
Fix to_number() to correctly ignore thousands separator when it's '.'.

The existing code in NUM_numpart_from_char has hard-wired logic to treat
'.' as decimal point, even when we're using a locale-aware format string
and the locale says that '.' is the thousands separator.  This results in
clearly wrong answers in FM mode (where we must be able to identify the
decimal point location), as per bug report from Patryk Kordylewski.

Since the initialization code in NUM_prepare_locale already sets up
Np->decimal as either the locale decimal-point string or "." depending
on which decimal-point format code was used, there's really no need to
have any extra logic at all in NUM_numpart_from_char: we only need to
test for a match to Np->decimal.

(Note: AFAICS there's nothing in here that explicitly checks for thousands
separators --- rather, any unmatched character is silently skipped over.
That's pretty bogus IMO but it's not the issue being complained of.)

This is a longstanding bug, but it's possible that some existing apps
are depending on '.' being recognized as decimal point even when using
a D format code.  Hence, no back-patch.  We should probably list this
as a potential incompatibility in the 9.3 release notes.
pg_xlogdump: Improve --help output
pgbench: Fix order of options in --help output