Robust, integer crosses for is_straight_line_drawing

[tinko92]

This PR, based on what I propose in boostorg/geometry#1434, drops the use of Boost.Geometry in is_straight_line_drawing.hpp in favour of a simple, int128-based test. This drops the dependency on Boost.Geometry and adds a dependency on Boost.Multiprecision (which would otherwise come transitively through BG):

This new test makes the assumption that coordinate values are integers.

It has the following semantics (If I didn't miss something) based on my understanding of the definition of planar drawing (non-parallel edges meet only at shared endpoints):

• An X-like crossing is a violation (same as before)
• A T-like crossing is a violation (no crossing in Boost.Geometry semantics)
• A partial overlap is a violation (no crossing in Boost.Geometry semantics)
• A complete overlap (parallel edge) is not a violation (same as before)
• Meeting only at one end point is not a violation (same as before)

If any change to this is desired, I can edit.

It should have the following robustness properties:

• If coordinate values lie in some integer interval not longer than 2^63, results should be correct. Boost.Geometry calculates exactly after conversion to doubles, but initial conversion to doubles may lose precision from 64-bit ints (more of a theoretical concern though, as it only happens above ~2^53).

Performance properties:

• I do not know how performance-critical this is and did not run benchmarks. If int128_t is an efficient compiler built-in, orientation2d may be (I expect) ~1-2x as expensive as side_robust. If this is a concern, I can edit the PR to add a classical double-based, ~6 LOC filter (if incorrectness for values above ~2^53 is no concern) or a not-so-classical double-based filter (that is more careful about large integers, slightly slower).

Tests run successfully (except isomorphism which also fails on develop for me due to cannot open file) on my device but its CPU is non-x86.