Generalizing Z_ORDER_LAT_LON indexes to handle indexes on a single
column, storing a spatial object.

- Previously, it was assumed that the number of arguments to
  Z_ORDER_LAT_LON was = dimensions (always 2). This is no longer
  true. Index.lastSpatialArgument() has been added, and the value is
  now stored in the AIS. akiban_information_system.proto has been
  modified, and lastSpatialArgument is initialized to
  firstSpatialArgument + 1 if not specified. That will provide
  compatibility with existing spatial indexes.

- At various places where index column types are checked, the
  assumption is that a blob storing a spatial object is a binary or
  character string or blob. I'm not positive that all of this checking
  is correct, and reviews should focus on this issue. I think it is
  reasonable to expect any of blob, text, varchar or varbinary for
  these columns -- binary columns for WKB, character for WKT or
  GeoJSON.

- A new test has been added, BoxTableIndexScanIT, but it is incomplete
  and @Ignored for now. It will test indexes on non-point spatial
  objects.

All tests work, and we can now declare an index containing
Z_ORDER_LAT_LON(x), where x is a blob, for example, but index creation
for this case hasn't been implemented yet.
Testing of z_order_lat_lon() on blob.
Removed the FDB implementation of spatial indexing (in the geophile
package), and using github.com/geophile/geophile instead. The
coordinate system of the space differs between the two, so most of the
work here involves dealing with that change. Now, spaces are described
by double precision coordinates, so the scaling that used to be done
(SpaceLatLon.scaleLat/Lon) is no longer needed.
Updated expected results of geospatial part of
RulesTest. Space.toString is different. And in some tests, expected
rows and costs changed, by approximately a factor of 2, e.g. from 3
rows to 7. This change is plausible, given the different approach to
coordinate systems and scaling used with the new version of geophile.
Addressed review comments.
Added new Value only constructor to TPreptimeValue
Removed redundant types

just use typeAt on the rowType
Made method calls not ambiguous
Added some more union tests
Added strict row/value type checks

Some or all of this might be reverted later. or at least disabled
Got union with nulls passing

It is producing a bunch of errors though, because it's trying
to evaluate something as a constant, but failing.
A bit more handling for strict type checking

See: e4078db2dba474a4cdec1609195374d05894f3f5
Removed null check for type check

Don't let null through, that should be checked too
almost there, fix broken tests
add the ambiguous collation exception
Update casts on underlying unions
Added prepared statement check to yaml test
Don't add unnecessary casts
Updated TypeResolver unit tests
Correctly union NULL constant and NOT NULL columns

the resulting type should be nullable