feat: major rewrite of traversal

[barendgehrels]

As per #1366

This is a big PR. Current stats:
85 files changed, 3955 insertions(+), 6767 deletions(-)

Fixes:

• Difference with rectilinear multipolygon with integer coordinates produces invalid polygon with disconnected interior #1221
• boost::geometry::intersection, wrong result (result polygon is equal to the biggest of the input polygons) #1295
• Difference of gpolygons giving wrong result #1349

Summary:

• it started using Boost.Graph to determine biconnected components, instead of our own isolation detection
• that's still there - but we can use it also for traversal
• that needed some time but it is now in a good shape.

Tests (as also reported earlier - but these are runs of today):

• random_bitset_grids:
  • develop: iterations: 100000 errors: 8 time: 48.776
  • this pr: iterations: 100000 errors: 0 time: 53.875 (better but still a bit slower, as reported in the discussion page)
• recursive_polygons_buffer:
  • develop: geometries: 148743 errors: 307 type: d time: 8.806 (miter)
  • this pr: geometries: 149509 errors: 111 type: d time: 7.817 (miter)
  • but with join round it is different:
  • develop: geometries: 147743 errors: 518 type: d time: 8.541 (round)
  • this pr: geometries: 146474 errors: 762 type: d time: 7.875 (round)
  • I investigated some cases - they were perfect, these were (3 cases) false negatives from valid. We should fix them.
• robustness_recursive_polygons
  • this pr: geometries: 1269839 errors: 9 type: d time: 86.551
  • develop: geometries: 1270000 errors: 0 type: d time: 92.921 - so a bit of regression here, should be investigated

Some things could not yet be fixed:

• the behaviour of start turns (removing then when not necessary) is not yet OK. There is a "concept fix" included (not active)
• the behaviour of get_turn_info is not always fine, especially where block_q is used. There is a "concept fix" included (not active)
• the behaviour of segment ratio at arrival is not always fine, also here is a "concept fix" included
• all these concept fixes should be worked out, as in this PR it's not fine everywhere. I can also omit it - but it is for your information
• also, the buffer often considers a turn (of two pieces, say A and B) inside another piece (say C), and another (say: of A and C) as well (say: in B). This is conceptually not possible and should be fixed
• and there are false negatives for invalidity, as mentioned above

[barendgehrels]

With respect to:

They were perfect, these were (3 cases) false negatives from valid

So, in some cases, the previous version delivered one polygon for a cluster of UX/XU turns. The current delivers two, which makes sense, it's a touching point (a cluster). Though there is around 5.0e-16 between them - so if you consider it really close, it should be one polygon.

When it is changed (it's relatively easy), the statistics are:
# geometries: 149315 errors: 221 type: d time: 8.063 (round) (so, also better than in develop now)

PostGIS: it finds both variants fine.

SQL Server: it considers only the one with two polygons as valid. So clustered turn. The other is invalid.