Re: Ryu floating point output patch

Rebased this patch onto current master. No functional changes; just
fixed up the copyright dates and a couple of stray missing UINT64CONSTs.

Regression tests still fail because how to fix them depends on the
issues below. Likewise docs are not changed yet for the same reason.

Decisions that need to be made in order to proceed:

1. Should exact output become the default, or is it more important to
preserve the historical output?

I will argue very strongly that the default output should be exact.

2. How far do we need to go to support existing uses of
extra_float_digits? For example, do we need a way for clients to
request that they get the exact same output as previously for
extra_float_digits=2 or 3, rather than just assuming that any
round-trip-exact value will do?

(this would likely mean adding a new GUC, rather than basing
everything off extra_float_digits as the patch does now)

3. Do we need to do anything about how conversions from floats to
numeric work? At present they _ignore_ extra_float_digits (presumably
on immutability grounds) and convert using only DBL_DIG digits of
precision.

I have no very strong position on this but incline to keeping the
existing behavior, though possibly it would be good to add functions
to get the round-trip value and possibly even the true exact value.
(It would be sort of nice if CAST(floatval AS numeric(400,18)) or
similar could work as you'd expect, but currently we treat that as
floatval::numeric::numeric(400,18) so the cast function doesn't know
about the eventual typmod.)

4. Can we allow declaration-after-statement please? That would allow
keeping this code significantly closer to its upstream.

--
Andrew (irc:RhodiumToad)