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.
I went by the 12/18 whiteboard / 12/19 email.
I think perhaps the argument then was the difference between a two-arg function (x and y overlap) and a one-arg method (x overlaps y).
I don't have any other vested interest.