simplify GeodesicPoly* classes a lot

[johnd0e]

Based on ideas from IITC-CE/ingress-intel-total-conversion#232

Main idea: do not store intermediate points.
Instead they are calculated on every projection (which typically occurs on zoom/viewreset).

• greatly simplify classes, and increase compatibility with L.Polyline-related routines (especially 3rd-party).
• changes in performance is unmeasured yet
  • memory footprint is lower
  • recalculations may be more frequent (unsure)

But besides mentioned benefits there is also plenty space for future improvement

• depend on zoom
• depend on map bounds
  • include lines/bounds intersections to points
  • clip to bounds (not calculate invisible parts)
  • more: see Geodesic accuracy #2

[johnd0e]

This PR introduces catching simplification, but we cannot merge it until we'll make tests to make sure that performance gets better with it.

[MysticJay]

To estimate on better performance:
Hard numbers in seconds depend too much on external parameters.
Instead count the number of calculations done and log the to console.

We know from the old routines that it did devide in to about 5km segments.
We also know that links that would cross map in one additional view around the center are calculated.

If we do not store the invisible nodes (intermediate points) any more, wouldn't that have the same effect as not calculating the "outside current view" areas, with all the negative impact on Map-pan actions.

[McBen]

Is there something similar which is called on every bounding box change.

RN I'm playing with the idea of cropping links at visual bounds.
LatLngs would be recalculated on every redraw.

Not sure about performance. Calculation is harmless. Redraw is the expensive part. But it would spare many lines and increase accuracy.