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.
Update the CursorBase to include the new states for the cursor. 

Expand the CursorLifecycle to include cursor states and checking. 

Update OperatorExecutionBase to match CursorBase
Update ChainedCursor to have the complete state changes management from
CursorBase implemented. 

Review all the simple cursor uses and replace as possible to use the
ChainedCursor with the consistent state transitions and verifications.
LeafCursor update. Leaf cursors are (as the name implies) at the leaf of
the operator tree, hence getting their rows from something other than an
input operator cursor. This has some fallout effects on cursors
generated elsewhere.
Add MultiChainedCursor, for processing operators with two inputs and one
output.
RowCursorImpl - A lower level implementation of the RowCursor interface
to capture all of the CursorBase state change information for the
remaining uses of RowCursor. These are largely not Operator cursors but
are scattered throughout the system: Index and Group cursors for
scanning store data, Spatial cursors, FullText cursor, Sorter cursors.
QueryBindingCursor -> Interleaved work with the bindings cursor. 

Updated the OperatorITBase cursor state test to be accurate. 

All files compile, but no tests run.
Two fixed from test failures in the base tests. Base tests now all pass.
Clean up some of the missed RowCursor.destroy() uses by odd corners of
the code. 

Get the RestServiceITs to pass, as well as GroupLookup_DefaultIT, which
was the source of many problems. I anticipate the enhanced state
checking will keep me busy for a while. 

Correct the assumed cursor states in the
OperatorITBase#testCursorLifecycle().
Next round of fixes. Tweaking location of open/close in
AncestorLookup_Nested$readAncestorRow()

Add working jump() call to ChainedCursor to allow tests to work
correctly.

Remove a redundant method call from MergeJoinSorter$KeyFinalCursor
logging jdbcstatement and rest errors
Merge remote-tracking branch 'fdb/master' into logging
changed multiplecause handling
Manage RowOrientedCursorBase#jump(). In the new order of things, calling
jump can only occur when 1) the cursor is ACTIVE/IDLE, and 2) resets the
state back to ACTIVE, so next() returns a actual row. 

In IndexCursorUnidirectional, move the endKey setup from Initializer to
open(). This accounts for calling close()/open() to set up the endKey
properly, but not manging it when calling jump().
undo log4j change
remove uneeded import list
fixed comment