Output POINT EMPTY in WKB using NaN as coordinate values

[pramsey]

Our old handling of overloading POINT EMPTY to convert into MULTIPOINT EMPTY results in outputs that are not actually consistent in type (that's a problem). A better hack would be using POINT(NaN NaN) to proxy for POINT EMPTY, since there's not much practical use for a POINT(NaN NaN) anyways. This means that database with "legitimate" POINT(NaN NaN) values would get them converted into POINT EMPTY on dump/restore, but that seems a small price to pay for the greater good.

This was discussed in #3031.

[pramsey]

Done in trunk only at r13707. Not patching back to 2.1 etc.

[robe]

broke sfcgal regress

 sfcgal/tickets .. failed (diff expected obtained: /projects/postgis/tmp/2.2.0dev_pg9.4_geos3.5.0dev_gdal2.0.0w64/test_116_diff)
-----------------------------------------------------------------------------
--- sfcgal/tickets_expected	2015-05-15 04:28:13 -0400
+++ /projects/postgis/tmp/2.2.0dev_pg9.4_geos3.5.0dev_gdal2.0.0w64/test_116_out	2015-06-25 16:31:23 -0400
@@ -184,7 +184,7 @@
 #1453.2|f
 #1454|t
 #1414|CURVEPOLYGON Z EMPTY
-#1478|MULTIPOINT EMPTY
+#1478|POINT EMPTY
 #745|GEOMETRYCOLLECTION(POLYGON((-72 42 1,-70 43 1,-71 41 1,-72 42 1)))
 #1450|POINT|POLYGON
 #1482|4326

[pramsey]

Altered that test at r13710

[strk]

Reopening as NaN was found not to be portable, see #3426

[pramsey]

Rather than using a dynamic NAN as we do now (using a #defined NAN or a calculated 0/0 NAN) what if we used an IEEE NAN all the time, just hardcode the bytes? It would then be portable. For weirdo platforms it might overlap a single legitimate value so we'd be taking a 1 in HUGE chance of collision, but I'd accept those terms.

[pramsey]

I'm closing this back out, please see ​https://trac.osgeo.org/postgis/ticket/3426#comment:11 for reasoning.