Updated onSegment.h and both segment intersections

[Chillee]

See #77.

This is a good win. Naively, we only use 24 lines now, compared to 50 lines previously. However, that isn't completely fair, as this new one introduces more dependencies. Even including all dependencies however, the functions required for the new SegmentIntersection.h total 21 lines, while the previous function was 27 lines.

I also shortened the function names (segmentIntersection is too verbose), in line with how most modern KACTL code is written.

I also changed the API a bit for SegmentIntersection.h. Instead of returning cnt and up to 2 points in separate variables, the new API simply returns a vector with 0,1, or 2 elements.

I deleted SegmentIntersectionQ.h, as I don't think there's much point in it anymore. Previously, SegmentIntersection.h was extremely verbose and had a somewhat cumbersome API where you'd need to create 2 dummy points even if you didn't want them. For the new API, you can use it very similarly to the old SegmentIntersectionQ.h if desired.

sz(segInter(a,b,c,d))>0 is equivalent to the old segmentIntersectionQ(a,b,c,d).

I also added a fuzz test trying a bunch of integer points on a 5x5 grid. I think trying integer points is the right thing to do, as an important part of this function is handling the "degenerate cases" correctly.

I also submitted to https://open.kattis.com/problems/segmentintersection and passed it with the new code: https://ideone.com/xT9jXo

Primary points of contention:

1. The new API change. I think it's better - is there any reason you'd have for preferring the old one?
2. I also added a function to Point.h: sgn(x). Simply returns the sign of a value, with some epsilon handling. My coach strongly suggested this as a good way of dealing with epsilons. I'm not sure what the philosophy is in KACTL for how to deal with epsilon issues in geometry, but I think this is a solid method.

[simonlindholm]

The new API change. I think it's better - is there any reason you'd have for preferring the old one?

The new version is definitely better. Easy to change to return a bool as well.

[simonlindholm]

Argh, pressed enter too early.

I also added a function to Point.h: sgn(x). Simply returns the sign of a value, with some epsilon handling. My coach strongly suggested this as a good way of dealing with epsilons. I'm not sure what the philosophy is in KACTL for how to deal with epsilon issues in geometry, but I think this is a solid method.

This is my main worry as well. Does one really want epsilon checks everywhere? I'm not sure... I'll need to ponder this.

Additionally, using sgn everywhere might be slightly slower than direct comparisons. (And it introduces a -Wconversion warning with ll, but then, it's easy to change to (x > 0) - (x < 0) when typing it in by hand.)

[Chillee]

If we want to handle the -Wconversion issue, it's easy enough to just do
(x>T(-EPS)) - (x<T(EPS)) as well.

[simonlindholm]

Looks good. I made a few comments.

[simonlindholm]

Also, I'm happy you changed sgn back to not use epsilons. The current behavior is sane for floats (if my thinking is correct it returns a result consistent with intersection of the input points moved around by epsilon); making it prefer special cases ("colinear is more likely than almost colinear") would require epsilons in a bunch more places than just the sgn's, and the epsilons would depend on the input coordinates and vary between sgn usages.