Faster route: part 1

[vadzim-vys]

Description

This PR introduces experimental "faster route" feature. For the first step I handled a case when the SDK receives an alternative which is faster than primary route, the SDK suggests the alternative as a faster route. But the SDK shouldn't suggest faster alternative if it's very similar to the alternative that was already rejected.

Test case

I used route from Munich to Nuremberg for testing. You will find recorded routes update with this route in unit tests.

You have two options: via Ingolstadt (faster) and Regensburg (slower).

If user picks the slower route via Regensburg and passes the fork point, the Navigation SDK generates a new alternative: turn around and go to the Nuremberg via Ingolstard, which is faster than primary route and has new alternative id.

The new alternative has a very similar geometry, so FasterRouteTracker rejects it as very similar to existing alternative.

Next steps

I won't handle all the cases in this PR because I prefer moving with small steps. I'm going to handle following things in the upcoming PRs:

1. ETA changes caused by route refresh. In theory, if traffic changes, rejected alternative can become even faster so it makes sense to suggest them again.

Routs similarity

I considered a few ways to calculate how similar routes are.

1. Calculate overlap of their geometry (the one I use in the PR)
2. Compare Route leg object summary using levinstein distance (iOS uses this)
3. Compare Route leg object summary, but parsing it and find shared roads names

I tested 3 of them.

I didn't like calculating Levinstein distance between leg's summaries like iOS does. For example if one route has "Maddison Avenue" the other has "Maddison Garden" their leveinstein distance is 6, what makes them pretty similar despite the fact that they're not.
I liked the result of comparing parsed summary + looking for how many roads name they have in common. See calculateDescriptionSimilarity. The problem is that Directions API doesn't guarantee stability of summary, it's design to be read by humans.
So I ended up comparing geometries.

Note for reviewers

The faster route feature isn't as clean as the rest of the SDK. But TBH I don't see much value in keeping experimental feature super clean as I don't know yet if we need it in the future. We will try to use it and then decide if it makes sense to have it at all. But if you see something very dirty that you won't accept even in experimental features, please comment and I will fix it.