First pass at snapped/following camera calculation

[ianthetechie]

We want the core to calculate most parameters so that all rendering frontends can implement the standard "following" camera consistently.

This information should be returned as part of TripState.

Components needed:

• [X] Snapped user location
• [x] Zoom level Distance (can be simplistic at first, but may get more dynamic over time based on things like distance to the next maneuver and speed)
• [X] Pitch (Configurable parameter set at init)
• [X] Smoothed heading (this will determine the orientation of the user's location arrow)
• [X] Smoothed Course over ground (the user's direction of actual travel, independent of compass readings, which can be quite bad in some situations)
• [x] Current deviation from the route line; useful for frontends to decide if they should show the real location or snapped one.

[ianthetechie]

We will get smoothed course eventually out of #23. Heading should be able to benefit from similar techniques. This isn't necessary for the first pass though, so I'm changing the descriptions of those.

Some more notes after further research in https://github.com/stadiamaps/ferrostar/issues/38#issuecomment-1987300282:

• Pitch will be fixed at initialization for now (this seems to work reasonably well in practice; we can improve later if needed).
• Zoom level is probably replaced by a distance parameter.

[ianthetechie]

Ok, so capturing the back and forth after discussion and a lot of work on implementation:

• Camera information will not live at the core (Rust) level
• First pass is implemented on iOS, with Android to follow
• We will build out interfaces that let users determine the camera parameters in each UI package (ex: Swift MapLibre frontend to Ferrostar) and provide reasonable defaults (static to start).

[ianthetechie]

We'll probably also need to have (in each platform + renderer pair) more than one way to customize cameras.

In the MapLibre world, for example, we'll want to support controlling the camera completely yourself, as well as keeping the "following" mode on but specifying a custom zoom level.

I THINK this zoom only control will be necessary since MapLibre seems to have its own internal logic for trying to smooth things when tracking and it makes sense to leverage that and push for improvements upstream as needed.

But full custom should also be supported. I'll work on this next week, with a focus on Android first.

[ianthetechie]

As far as I can tell, #95 finishes everything we could possibly want on iOS, but we still need to basically port the same stuff back to Android. I think your recent compose work on Android @Archdoog has also enabled the same behaviors, but it just needs to be exposed in the NavigationMapView.