fix: handle GeoJSON locations when computing distance between stops

[sylvansson]

Summary:

This PR fixes a bug where we calculate the distance between two stops incorrectly if there's a GeoJSON location between them. We currently fall back to Null Island (0, 0) when we can't get the coordinates of a stop time's stop (in this case, because there's no stop id for a GeoJSON location) which messes up our calculations and can lead to false positives for the fast_travel_between_far_stops notice. See this comment.

We also address false negatives for the fast_travel_between_consecutive_stops notice due to only comparing consecutive entries in stop_times.txt.

I'll write some tests once we're happy with the approach.

Closes #2031

Expected behavior:

• We don't get a fast_travel_between_far_stops notice when two stops are within a reasonable distance but there's a GeoJSON location between them.
• We get a fast_travel_between_consecutive_stops notice when two consecutive stops are too far apart and there's a GeoJSON location between them.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with gradle test to make sure you didn't break anything
• Add or update any needed documentation to the repo
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)

[sylvansson]

I see some of the tests are failing. I need to look into that.

[sylvansson]

I think this is ready for review, sorry for the delay.

[sylvansson]

Since we now skip stops when we can't compute the distance or speed, we sometimes effectively check non-consecutive stops, which feels slightly misleading. If needed I can adjust the logic to only emit a notice for strictly consecutive entries.

cc: @davidgamez @emmambd