Ordered GeoJSON according to bounding box circumfence.

The drawback is still that we have to check all the GeoJSON sizes and store
properties temporarily. For 10000+ docs there is a considerable latency. Maybe
we'll never get there???! Also the JSON response body accepts an array of
types in case we want to restrict output.
Introduced sort_index parameter to spacial indexing.

If sort_index is specified as a number in the request body, it will be used to
decide if rows are sorted according to size after a certain index. The idea
behind this goes as follows:
* client obtains an ordered geometry list [a,b..h] and queries
  _lists/bbox-filter with {keys:[a,b..h], sort_index:0, limit:3, bbox:[..]}
* filter returns [a,b,e] that fall inside bbox. Every row needs to be checked.
* Client puts [a,b,e] in front of the list for the next query.
* So the list reads [a,b,e,c,d,f..h] and sort_index is 3 because there are three
  unsorted items and the rest is still in descending order.
* If filter is queried with the same bbox, it only has to check til f.
* If queried with an infinite bbox, it only checks up to d and returns [a,b,c].
* The Client now has [a,b,e] as old prefix and removes a,b from it. c is
  removed from the sorted suffix. e remains in the old prefix. This yields
  [a,b,c][e][d,f..h]. Old and new prefix are merged, sort_index becomes 4.
Moved bbox and size to CommonJS lib 'views/lib/utils'.

I most certainly will need the stupid bbox calculation again for filtered
replication and other views etc.
Allowed _list/tabulate to check if a regexp matches the stringified row.

Syntax is of course similar to _update/substitute:
  /_list/tabulate/<view>?/<pattern>/<flags>&<...>
If multiple expressions are used, they all have to match.