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.
Addressed review comments.
Resolved merge conflict.

Merge branch 'master' of https://github.com/FoundationDB/sql-layer into geophile-integration

Conflicts:
	src/test/resources/com/foundationdb/sql/pg/yaml/functional/test-spatial-index.yaml
merge geophile: Generalizing Z_ORDER_LAT_LON indexes to handle indexes on a single

Merge pull request #1416 from geophile/sql-layer/geophile-integration
https://github.com/FoundationDB/sql-layer/pull/1416