Float64Range and Float64Set (first half of #153) #196

The double half of #153, split out so it can merge on its own; Float32Range/Float32Set follow in a stacked PR that closes #153. The design is #153's, unchanged.

Measured on PostgreSQL 16 and 18 (scratch containers), held on 17 by the integration suite:

• The [5,NaN) / [NaN,5) / [0,) @> NaN / [1,Infinity) rows of Float64Range/Float64Set and Float32Range/Float32Set over finite values only, mapped to custom float8range and float4range #153 reproduce on 16 and 18.
• float8out at extra_float_digits 1 is Ryu built with acceptBounds = false (STRICTLY_SHORTEST undefined in src/common/d2s.c), laid out in fixed notation for decimal exponents −4…14 and as d.ddde±xx otherwise. .NET's shortest form differs in layout for most exponent-form values and in digits for 128 of 40,016 sampled doubles (1e23 → PG 9.999999999999999e+22), always reading back as the same value — except two.
• .NET 10 defect: double.ToString() / "R" (and System.Text.Json's writer) print 2^-25 as 2.980232238769531E-08 and 2^-958 as 4.104536801298376E-289, which read back one ulp lower. Exhaustive over the neighbourhood of every power of two and 0 of 20M random doubles otherwise; no float failures sampled.
• A PG-exact formatter (Internals/FloatLiteral.cs) matches float8out on 649,929 doubles on 16 and 18, 0 mismatches.
• CREATE TYPE … (subtype = float8, subtype_diff = float8mi): inserting or indexing extreme values under GiST fails with 22003 value out of range: overflow on 16 and 18; without the diff the index builds and answers.
• float8in accepts C strtod hexadecimal (0x10) on musl; the family refuses it (and NaN/inf/out-of-range text, where double.Parse silently returns infinity or zero).