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)