bugfix and simpler code

[rikojacob]

The original code of get_nearest_location(location) has the property that if 'location' is a point on the track, the point after 'location' on the track is returned (for that case 'not distance' is True because distance is 0.0).
There is a version that only adjusts for this behavior in the middle commit.
I consider the version using min(..,key=lambda ..) even more readable.

One could consider this a hotfix, so perhaps it should be a pull request on master. If you prefer this, I can prepare such a pull request. (I'll have to do it from a different fork because this one has the full merge of dev...)

[coveralls]

Coverage increased (+0.9%) to 87.753% when pulling c808826 on rikojacob:dev into ac394b9 on tkrajina:dev.

[tkrajina]

Thanks @rikojacob! Can you also provide a test? For example use one of the provided test tracks, loop through points and make sure get_nearest_location returns those same points.

PS. Don't worry about dev/master I'll merge it in master.

[rikojacob]

Done, slightly differently, including some tests if None is handled as expected.
I also changed a type annotation in a separate commit.

[rikojacob]

Now everything is based on walk(), no test fails, no type errors in new code.
I'll leave it for the moment.

Two more general comments:
In python, -1 is a bad default value for indices (like the track index in Segment.get_nearest..) because it can be used as an index referencing to the last entry.

Perhaps it would make sense to change NearestLocationData to LocationData and make it the type of elements walk() returns

[tkrajina]

Merged, thanks!