Allowed for a slight wiggle room for bbox spatial relations.

The tolerance is identical to the 5e-7 in utils/pointInPolygon and accounts for
about 55mm.
Sensibilized pointInPolygon() for points close to line segments.

The commit looks like a mess because everything needed review.

For the signature with known_point, vector cross products are written to
operate with p-q, p-a, a-b, b-q in that order:
- p-q is constant,
- p-a is used to check if a is close to b,
- a-b is then used to to check if p is close to a-b. The actual distance
  (a-b) x (p-a) / |a-b| was approximated by using abs(ba_u)+abs(ba_v) instead
  of a square root. This is faster and the error is within 42%.
- Last b-q is needed to check CCW(p,a,b)!=CCW(q,a,b) && CCW(a,p,q)!=CCW(b,p,q)
  expressed as (p-a)x(a-b) == (a-b)x(b-q) and (p-a)x(p-q) == (p-q)x(b-q).
For the signature without known point, I removed a bunch of precautions for
unlikely cases and worked around comparisons with absolute zero.
Fixed bad logic for on-boundary points.

It astounds me that the entire time this just gave the impression of working,
when in fact it was very very bad programming:
For within/countains, pointInPolygon must be called with inside=false if no
known_point is given. The handling of points on boundary did exactly the
opposite.
Turns out I suck at math.
Reverted to one hard-coded snap-level of 5e-7.

Initially my intention was to factor in that |b-a| lies within |ba*u|+|ba*v|
and (|ba*u|+|ba*v|)/sqrt(2). Also I factored in that no one is allowed to
overthink my reasoning.
Moved initialization of b-a to where it is needed.
Turns out I also suck at programming.

The tolerance that I introduced to conditions on single coordinates lead to
double counting intersections and also was not needed at all: If p happens to
be close to b, on_boundary would be thrown at the next iteration anyway.
This just re-arranges some lines for comprehensibility.