Stashed ignored geometries for later use.
This allows the coordinate loop to terminate early.
Reformatted to a switch statement() for later use.
This is a draft of spatial 'intersects'.

The simplified workflow outlines as such (vars in upper case and relations
start with a capital this time):
- In case of Contains/Intersects, split posted geometry into dim-2
  (->RELATED_GEOJSON) and dim-1,0 objects (->SKIPPED).
- In case of Within, store the entire posted geometry into RELATED_GEOJSON.
- In case of Contains/Intersects, determine one point and its side-ness w/r/t
  RELATED_GEOJSON.
- In case of Contains, set RELATES to a function that returns true, only if all
  points of a given GEOJSON are inside RELATED_GEOJSON. As soon as one point is
  found to be outside RELATED_GEOJSON, RELATES quits early and returns false.
- In case of Intersects, set OUTSIDE_RELATED_GEOJSON to a function that returns
  true, if all points of GEOJSON lie outside RELATED_GEOJSON; This is the same
  function as above, just with the side-ness flipped (neat).
- In case of Within, set RELATES to a function that returns true if all points
  of RELATED_GEOJSON lie inside a given GEOJSON.
- In case of Intersects, set SKIPPED_OUTSIDE to a function that returns true if
  all points of SKIPPED lie outside a given GEOJSON; Again, this is the same as
  above, save flipped sideness and different set of points.
- In case of Intersects, set RELATES TO
    GEOJSON --> !OUTSIDE_RELATED_GEOJSON(GEOJSON) || !SKIPPED_OUTSIDE(GEOJSON)
  because !OUTSIDE_RELATED_GEOJSON states that at least one point of GeoJSON is
  inside RELATED_GEOJSON and this already qualifies as intersection (ditto for
  the other part).
Second draft, slightly different workflow.

- Instead of storing LineStrings etc. in SKIPPED, I stored the entire posted
  geometry as RELATED_GEOJSON regardless of the requested relation and it
  remains unaltered. Then I copy all the dim-2 objects out of it into
  RELATED_POLYGONS.
  This version is probably more secure because the previous
  version assumed that, having no points of polygon B within polygon A means
  that no points of polygon A are in polygon B as well.
- Stripped and un-stripped polygons are properly taken care of. The former
  completely spoil point-in-polygon checks, whereas the latter may cause
  end-points to be checked twice.
Removed some redundant anonymous function brackets.
Removed unused break label and objects.
This fixes a dozen logical flaws.

Setting 'relates' to 'fail' by default broke my entire application. Also I
confused it with 'relation' and it would have messed up the combination of
'outside_related_Polygons' and 'related_GeoJSON_outside' below. It still looks
confusing though.
Worked around the need of a bounding box for initialization.

I realized just now that, by design, utils/pointInPolygon() just flips the
'inside' argument around even if no known_point is set, tee hee.
Fixed what must have been a typo.
Fixed badly contructed points loop.
Simplified _list/bbox-filter output.

At the end of the day I will only need the geometry id (when applied to
_view/geojson) or bbox and geometry error (when applied to _view/bbox).
Protected relate function against unspecified geometry.
Suppressed spatial relation set-up if options.bbox is set.

I expect the use-case to be _list/bbox-filter/bbox with options.bbox and
options.relation, and req.body.keys - and then _list/bbox-filter/geojson
without options.bbox, but including options.geojson and req.body.keys.
What I don't see is options.bbox and req.body.GeoJSON.
Simplified spatial relation set-up.

All these ( related_GeoJSON.type && ...) formatted statements provided for the
case that options.relation was set, but without a request body.
I guess out of pragmatism, the JS in operator has lower precedence than logical
operators, so I don't have to flood my screen with stupid parenthesis.