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".  (The approach to "Value locking" presenting here follows
design #2, as described on
https://wiki.postgresql.org/wiki/Value_locking).  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

CONFLICTING is a function-like 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.  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
users writing very verbose queries, with a great deal of redundancy in
the UPDATE auxiliary query to work around the lack of this additional
facility.  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 proposed as a starting
value for insertion.

The effects of BEFORE INSERT 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).

This commit adds a new primnode, ConflictExpr, to implement the new
expression.  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/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.

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 executor README.  A high-level handling of
approach #2 to value locking also appears there, since in contrast with
design #1, that is something that lives in the head of the executor.
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 -- statement level UPDATE triggers will not fire when
INSERT ... ON CONFLICT UPDATE is executed, 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.  In principle it is
the responsibility of writable foreign data wrapper authors to provide
appropriate support for this new clause (although it's hard to see how
the optional "WITHIN `unique_index`" clause could work there).

Finally, a user-level description of the new "MVCC violation" that
INSERT ... ON CONFLICT {UPDATE | IGNORE} sometimes requires has been
added to "Chapter 13 - Concurrency Control", beside existing commentary
on Read Committed mode's special handling of concurrent updates, and the
implications for snapshot isolation (i.e.  what is internally referred
to as the EvalPlanQual() mechanism).  The new "MVCC violation"
introduced seems somewhat distinct from the existing one, 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).