sortsupport for text

Virtually identical to the 2012 Robert Haas patch discussed at
CA+Tgmoa8by24gd+YbuPX=5gSGmN0w5sGiPzWwq7_8iS26vL5CQ@mail.gmail.com.

On Windows, when the UTF-8 encoding is used without the "C" locale, sortsupport
optimization is not used because the cost of converting to UTF-16 (which the
available Microsoft API effectively necessitates) is presumed to dominate, and
it doesn't seem worth replicating the varstr_cmp() hacks that make that work in
the new sortsupport comparators.  This was not addressed by the earlier patch.

However, since commit 1d41739e5a04b0e93304d24d864b6bfa3efc45f2
established that it is not strictly necessary to provide a sane sort
support routine with a comparator when an opclass has a cataloged
sortsupport routine, we return early on Windows + UTF-8 without
assigning a comparator, and leave it to sortsupport to set up a shim
comparator.
Abbreviated sortsupport keys

Add a new infrastructure to sortsupport, and add a single client of this new
infrastructure, the text sortsupport routine.  This infrastructure allows
opclasses whose sortsupport routines support this additional, optional new
capability to provide abbreviated representations of Datums in advance of
sorting, generated through an opclass-specific encoding scheme.  An abbreviated
representation is typically pass by value, and the capability is thought to
mostly be useful for pass by reference types, but there are no hard
requirements on representation.

Opclasses that support this new capability provide a special abbreviation-aware
comparator (in addition to the usual, ordinary sortsupport fmgr-eliding
comparator).  This comparator returns a value less than, equal to, or greater
than 0, in a manner similar to the usual fmgr-eliding comparator (which is to
say, a manner similar to any btree support function 1).  However, there is an
important difference:  sortsupport clients such as tuplesort interpret the
value 0 as "inconclusive".  Inconclusive comparisons obligate these clients to
perform a tie-breaker ordinary comparison in respect of the same attribute.

By generating abbreviated keys, the optimization can speed up internal sorts
considerably.  Because of the high cost of CPU cache stalls when sorting, cache
efficiency is a crucial consideration in engineering sorting algorithms and
related infrastructure.  Pass by value representations have much greater
temporal and spatial locality than pass by reference representations.
Furthermore, the abbreviation-aware comparisons can themselves be far cheaper
than an authoritative comparison, if the abbreviation encoding scheme can
produce a "reductionist" representation sufficient to resolve most comparisons.
Encoding may be expensive, but if an encoding process can occur N times, rather
than having essentially the same encoding process occur N log N times, that can
be a highly effective optimization.

The expense of encoding may well be problematic if no benefit can be derived
from abbreviated keys during sorting, though.  Opclasses supporting abbreviated
keys also provide an "abort" callback, which hints the number of rows to be
sorted in total, and progress so far.  This can either abort the abbreviation
encoding process entirely, or give the encoding scheme the ability to adapt its
encoding strategy in order to maximize the number of comparisons that are
resolved with abbreviated keys.  HyperLogLog, a cardinality estimator algorithm
is added to give clients of the new sortsupport infrastructure a principled way
to estimate the usefullness of encoding.

Currently, only the MinimalTuple tuplesort case uses abbreviated keys.

Support for abbreviation within text sortsupport works by copying the first 8
bytes of a strxfrm()-returned blob to an 8 byte Datum.  Abbreviation-aware
comparisons are simple memcmp() comparisons of this representation.
Tie-breakers optimistically attempt to get away with a simple memcmp() of the
original text string before an expensive strcoll() is performed.
Temp debug instrumentation
Basic ICU support
Revert "Basic ICU support"

This reverts commit a52e1a373a28a1392e15a580be0ec598b95725ab.