Support INSERT ... ON CONFLICT {UPDATE | IGNORE}

This non-standard INSERT clause allows DML statement authors to specify
that in the event of each of any of the tuples being inserted
duplicating an existing tuple in terms of a value or set of values
constrained by a unique index, an alternative path may be taken.  The
statement may alternatively IGNORE the tuple being inserted without
raising an error, or go to UPDATE the existing tuple whose value is
duplicated by a value within one single tuple proposed for insertion.
The implementation loops until either an insert or an UPDATE/IGNORE
occurs.  No existing tuple may be affected more than once per INSERT.

This is implemented using a new infrastructure called "speculative
insertion".  A speculative inserter establishes the right to insert
ahead of time.  In order to proceed with insertion, consensus must be
reached between all unique indexes on the table, or else the alternative
path is taken.  Finally, heap tuple insertion occurs in the conventional
manner, followed by insertion of index tuples, where index tuple
insertion picks up where value locking left off, performing essentially
the conventional insertion process in a staggered fashion.
Alternatively, we may go to UPDATE, using the EvalPlanQual() mechanism
to execute a special auxiliary plan.

READ COMMITTED isolation level is permitted to UPDATE a tuple even where
no version is visible to the command's MVCC snapshot.  Similarly, any
query predicate associated with the UPDATE portion of the new statement
need only satisfy an already locked, conclusively committed and visible
conflict tuple.  When the predicate isn't satisfied, the tuple is still
locked, which implies that at READ COMMITTED, a tuple may be locked
without any version being visible to the command's MVCC snapshot.

Users may optionally specify a single unique index to merge on with a
WITHIN `unique_index` specification, which is useful when there is a
concern about spuriously merging on the wrong unique index due to there
being more than one would-be unique violation.  Otherwise, we UPDATE (or
IGNORE) based on the first would-be unique violation detected, on the
assumption that that is the only unique index where a violation could
appear.

The auxiliary ModifyTable plan used by the UPDATE portion of the new
statement is not formally a subplan of its parent INSERT ModifyTable
plan.  Rather, it's an independently planned subquery, whose execution
is tightly driven by its parent.  Special auxiliary state pertaining to
the auxiliary UPDATE is tracked by its parent through all stages of
query execution.

The optimizer imposes some restrictions on child auxiliary UPDATE plans,
which make the plans comport with their parent to the extent required
during the executor stage.  One user-visible consequences of this is
that the special auxiliary UPDATE query cannot have subselects within
its targetlist or WHERE clause.  UPDATEs may not reference any other
table, and UPDATE FROM is disallowed.  INSERT's RETURNING clause
continues to only project tuples actually inserted.
CONFLICTING expressions within ON CONFLICT UPDATE

Add the ability to reference rejected-for-insertion tuples within both
the targetlist and predicate of the ON CONFLICT UPDATE portion of an
INSERT ... ON CONFLICT UPDATE query.  This is particularly useful for
such queries that propose multiple tuples for insertion, since it isn't
otherwise possible to succinctly distinguish which actual tuple is being
updated, and so which actual values to update each with in the event of
having to update.  One can imagine writing very verbose queries, with a
great deal of redundancy in the UPDATE auxiliary query to work around
this limitation.  Frequently, multi-tuple INSERT ...  ON CONFLICT UPDATE
queries will be written so as to merge values in a straightforward
manner, as when a few columns from the INSERT's tuple are referenced as
assigned-from within the UPDATE's targetlist, or as when a counter
column value is UPDATE-incremented by a value originally proposed as a
starting value for insertion.

The effects of BEFORE INSERT triggers 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 transformations occurring
when both INSERT and UPDATE triggers are fired for the same tuple should
be considered.  It's possible to imagine a use case in which this isn't
desirable, and is even surprising -- essentially the same transformation
may undesirably occur twice.  (It might also be the case that
side-effects occur for both, but writing triggers with external
side-effects is already considered questionable for several reasons, and
besides, we cannot reasonably prevent this, as noted in nodeModifyTable
comments from a previous commit).

This adds a new primnode, ConflictExpr.  For the most part, this is a
simple shim on a Var (initially a ColumnRef) referencing the target
table.  However, speculative insertion/the executor arranges to rig the
Vars and UPDATE-related EQP expression context such that values will
actually originate from the rejected tuple, per slot proposed for
insertion as appropriate.  This is somewhat similar to the handling of
trigger WHEN clauses.

With this commit, the feature is functionally complete.  Previously
noted as an open item in:

CAM3SWZTEODEJLz82LK4eF2HYX+qEKrbc8-Vtq3_-aOf6kRSfiA@mail.gmail.com
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.  Regression tests are for the
most part intended to exercise interactions with inter-related features.
Add a few general purpose smoke tests too.
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.