Horace He

I believe this is now ready for review. Previously I was using MIT's code to benchmark, but MIT's code seems to fail on this case: https://ideone.com/gPbt7X, which corresponds to these...

Thanks to @xyzhan, I found a bug in the current half-plane code. Need to think about how to address it. I would also have found the bug if I ran...

Precision starts to become a large issue even with very small inputs. See this example ```cpp vector t({{P(8,9),P(8,2)},{P(3,9),P(5,2)},{P(8,2),P(8,3)},{P(7,2),P(1,7)},{P(1,0),P(7,1)},{P(9,2),P(5,6)},{P(10,10),P(-10,10)},{P(-10,10),P(-10,-10)},{P(-10,-10),P(10,-10)},{P(10,-10),P(10,10)}}); auto res = halfPlaneIntersection(t); cout

Somewhat interestingly, it seems like `lineInter2` barely makes a difference in accuracy, but it seems to be enough to matter (ie: `lineinter2` passes all the fuzz-tests, `lineinter` doesn't). I'll note...

Ok, I've updated with a stable version. It currently passes some fairly exhaustive fuzz testing.

Ok, so I modified the `halfplane.h` to use fuzzy results for line intersection, and I played around with various values of EPS for `sideOf`. The code looks like this: ```...

I was more thinking that after I finish writing this we get rid of the old Polynomial class entirely. I don't think there's much point for it.

There's not much in the old Polynomial class, it's not documented, etc. I made a new file simply so things don't break while I write the new version and that...

Ok then, if you insist :^)

I rebased upon the `FFTMod` PR since this code depends on that. I made a couple changes to `ModularArithmetic.h` to make it fit better with this code.