EXCLUDED expressions within ON CONFLICT UPDATE

EXCLUDED.* (which previously appeared as EXCLUDED(),and CONFLICTING()
before that) is an "internal" primnode expression which enables
referencing of rejected-for-insertion tuples within both the targetlist
and predicate of the UPDATE portion of an INSERT ... ON CONFLICT UPDATE
query.  The expression is invoked using an alias-like syntax (more on
how this works later).  The fact that a dedicated expression is used
(rather than a dedicated range table entry involved in query
optimization) is an implementation detail.

This additional support is particularly useful for ON CONFLICT queries
that propose multiple tuples for insertion, since it isn't otherwise
possible to succinctly decide which actual values to update each column
with (in the event of taking the update path in respect of a given
slot).

The effects of BEFORE INSERT row triggers on the slot/tuple proposed for
insertion are carried.  This seems logical, since it might be the case
that the rejected values would not have been rejected had some BEFORE
INSERT trigger been disabled.  On the other hand, the potential hazards
around equivalent modifications occurring when both INSERT and UPDATE
BEFORE triggers are fired for the same slot/tuple should be considered
by client applications.  It's possible to imagine a use case in which
this behavior is surprising and undesirable -- essentially the same
non-idempotent modification may occur twice.  (It might also be the case
that BEFORE trigger related side-effects undesirably occur twice, but
writing BEFORE triggers with external side-effects is already considered
a questionable practice for several reasons (consider commit 6868ed74),
and besides, the implementation cannot reasonably prevent this, as noted
in nodeModifyTable.c comments added by the main ON CONFLICT commit).

In this revision, the raw grammar does not generate an ExcludedExpr.
Parse analysis of ON CONFLICT UPDATE is made to add a new relation RTE
to the auxiliary sub_pstate parser state (an alias for the target).
This makes parse analysis build a query tree that is more or less
consistent with there actually being an EXCLUDED relation.  Then, as
part of query rewrite, immediately after normalizing the UPDATE
targetlist, Vars referencing the pseudo-relation (using the EXCLUDED
alias) are replaced with ExcludedExpr that references Vars in the target
relation itself.

Speculative insertion/the executor arranges to rig the Vars and
UPDATE-related/EPQ scan planstate's expression context such that values
will actually originate from the rejected tuple's slot (driven, as
always for the UPDATE's execution, by the parent INSERT ModifyTable
node, changed once per slot proposed for insertion as appropriate).
This whole mechanism is somewhat similar to the handling of trigger WHEN
clauses, where a similar dance must also occur within the executor.

Note that pg_stat_statements does not fingerprint ExludedExpr, because
it cannot appear in the pre-rewrite post parse analysis query tree. (It
doesn't fingerprint every primnodes anyway, mostly because some are only
expected in utility statements).  Other existing Node handling sites
that don't expect to see primnodes that appear only after rewriting
(ExcludedExpr may be in its own category here) do not have an
ExcludedExpr case added either.
Tests for INSERT ... ON CONFLICT {UPDATE | IGNORE}

Add dedicated isolation tests for both UPDATE and IGNORE variants,
illustrating the "MVCC violation" that allows a READ COMMITTED
transaction's UPDATE to succeed in updating a tuple with no version
visible to its command's MVCC snapshot.  Add regression tests, which for
the most part are intended to exercise interactions with other features
(e.g.  updatable views, inheritance, triggers).

Add a few general purpose smoke tests too, testing everything from
EXPLAIN output to unique index inference.
Internal documentation for INSERT ... ON CONFLICT {UPDATE | IGNORE}

Includes documentation for both the nbtree and executor READMEs, as well
as the user-facing SGML documentation around index AMs.  The latter two
additions should make clear how the AM interface has been revised for
amcanunique AMs in the abstract, without reference to the only current
implementation, nbtree.
User-visible documentation for INSERT ... ON CONFLICT {UPDATE | IGNORE}

INSERT ... ON CONFLICT {UPDATE | IGNORE} is documented as a new clause
of the INSERT command.  Some potentially surprising interactions with
triggers are noted -- BEFORE INSERT per-row triggers must fire without
the INSERT path necessarily being taken, for example.

All the existing features that INSERT ... ON CONFLICT {UPDATE | IGNORE}
fails to completely play nice with have those limitations noted.  (Notes
are added to the existing documentation for those other features,
although some of these cases will need to be revisited).  This includes
postgres_fdw, updatable views and table inheritance (although these have
most interesting cases covered, particularly inheritance).

Finally, a user-level description of the new "MVCC violation" that the
ON CONFLICT UPDATE variant sometimes requires has been added to "Chapter
13 - Concurrency Control", beside existing commentary on READ COMMITTED
mode's special handling of concurrent updates.  The new "MVCC violation"
introduced seems somewhat distinct from the existing one (i.e.  what is
internally referred to as the EvalPlanQual() mechanism), because in READ
COMMITTED mode it is no longer necessary for any row version to be
conventionally visible to the command's MVCC snapshot for an UPDATE of
the row to occur (or for the row to be locked, should the WHERE clause
predicate not be satisfied).