Improve latlon performance

[scyrock]

This draft replaces expensive latlon3 wrapper calls in geographic helpers with direct reusable pyproj.Geod calls.
The goal is to keep the same WGS84/spherical geodesic behavior while avoiding repeated object construction, repeated Geod construction, string formatting, and string parsing in routing hot paths.

Added scripts/benchmark_latlon.py to compare the old latlon path against the new direct pyproj path for:

• point_distance
• routage_point_distance
• lossodromic

Number of iterations: 10000
>> utils.point_distance <<
Sum relative error = 0.000E+00
latlon time:      1.148272
pyproj time time: 0.095083
time reduction:   12.1x

>> utils.routage_point_distance <<
Sum errors =      1.063E-12
latlon time:      1.446403
pyproj time time: 0.118104
time reduction:   12.2x

>> utils.lossodromic <<
Sum relative error (distance) = 0.000E+00
Sum relative error (angle) =    1.106E-15
latlon time:      1.382446
pyproj time time: 0.123218
time reduction:   11.2x

[scyrock]

Expected Performance Improvement

Using the current test suite as a rough routing benchmark, with a minor temporary fix for tests/shortestpathrouter_test.py::TestRoutingNoIsland (see below), I averaged the runtime over 10 runs.
Baseline (latlon):

Test time - runs: 10
max:      113.005s
mean:     101.295s

Proposed (pyproj):

Test time - runs: 10
max:      24.573s
mean:     17.482s

TestRoutingNoIsland

The proposed change exposes a brittle assertion in tests/shortestpathrouter_test.py::TestRoutingNoIsland. The test uses the length of the serialized GeoJSON output as a reference value. This is a rough proxy for correctness and is sensitive to insignificant floating-point representation differences.
Comparing the route produced by the baseline library with the route produced by this PR shows that the route is effectively unchanged. The same route structure, timestamps, predecessor chain, endpoint, wind values, speed, and headings are preserved. The differences are only floating-point tail differences.

[IsoPoint(pos=(5, 38),
prev_idx=-1,
time=datetime.datetime(2021, 4, 2, 12, 0),
twd=0,
tws=0,
speed=0,
brg=0,
- next_wp_dist=16.911382104938177,
+ next_wp_dist=16.9113821049388,
start_wp_los=(0, 0)),

IsoPoint(pos=(5.152476865788411,
-                 38.02823298314942),
+                 38.02823298314943),
prev_idx=0,
time=datetime.datetime(2021, 4, 2, 13, 0),
twd=3.23788342619618,
tws=4.00683857723268,
speed=5.0,
brg=10.517054876399895,
- next_wp_dist=10.66705389771147,
+ next_wp_dist=10.66705389771185,
- start_wp_los=(17.240604798532974,
-                 0.18355723520605569)),
+ start_wp_los=(17.240604798533063,
+                 0.183557235206099)),

IsoPoint(pos=(5.1904822898925635,
-                 38.1781983289182),
+                 38.17819832891819),
prev_idx=7,
time=datetime.datetime(2021, 4, 2, 14, 0),
twd=3.0684198516790833,
tws=3.797129610468381,
speed=5.0,
brg=75.80750727536952,
- next_wp_dist=1.4234678174211945,
- start_wp_los=(28.950766463146227,
-                 0.7533037702691157)),
+ next_wp_dist=1.423467817422433,
+ start_wp_los=(28.950766463145875,
+                 0.7533037702690986)),

IsoPoint(pos=(5.2, 38.2),
prev_idx=-1,
time=None,
twd=0,
tws=0,
speed=0,
brg=0,
next_wp_dist=0,
start_wp_los=(0, 0))]

The coordinate drift is negligible. This should not be treated as a routing regression.
A more suitable test could assert route properties with numeric tolerances, such as the number of steps, the final timestamp, the path length, the endpoint, and the distance between expected and actual coordinates, instead of json.dumps(path_as_geojson(...)).