Optimizer support for new spatial query interface

I believe this has the general flavor of what was agreed upon. I am not certain that I got the intent for the `IndexKeyRange` representation. As of this branch, the boundary expression always evaluate to a `Geometry` object in the `AkGeometry` type. If there is only one, that means a Z-order iteration from there outward (if we still want to support that). If both (and low and high will be identical), it's the object to join with. In non-trivial cases, the bound expression will be a call to one of the new `GEO_` functions, a few more of which are included here.

I am also uncertain that I got the `GEO_BUFFER` function used to "inflate" a distance joining right.

All the old syntax still works, since keeping it gives a more direct comparison for how things work here: see .expected file changes.

I do not think that I introduced any new test failures, though there is still no complete end-to-end test. If that's correct, this could be merged now. Or @geophile could use this as a basis for a larger proposal.
Most of these seem to be taking a foo.func(bar) -> geo_func(foo, bar) conversion. I think I'd vote to make that predictable across the board. I have no other arguments for it though.