Update Default Zoom Level

[sarahsnow1]

This PR lays the foundation for providing an easy way to customize the camera via a new abstract Camera class which can be set with MapboxNavigation#setCameraEngine. It moves the camera positioning logic from NavigationCamera into a new class SimpleCamera. By default, MapboxNavigation now uses an instance of SimpleCamera to determine how the camera should be position while routing. SimpleCamera's default zoom values have also been updated so that they are consistent with iOS.

Further work can use the properties passed in RouteInformation to determine whether the user is starting the route, in the middle of it, or at their destination.

• Provide screenshot references
• Add test coverage for SimpleCamera (verify correct values returned, verify initial values cached)

Closes #602

[danesfeder]

I think it would make sense to re-exclude these modules to prevent duplicate imports. mapboxServices is the 2.2.9 version of our services library, which we are using for just telemetry at the moment. mapboxSdkServices is the 3.0.0 of the library and includes the modules above. Sorry for the confusion on this as we transition these libraries!

[sarahsnow1]

Whoops- okay, they are now re-excluded. Thanks for clarifying!

[danesfeder]

@sarahlensing Thanks for the work on this - this will make it a lot easier to drive a dynamic camera along a route. Just a minor comment regarding re-excluding those dependencies.

@ericrwolfe Bumping the zoom by one and keeping the same target distance pushes the puck further into the middle of the map:

The way we calculate the target distance based on the NavigationView and overall screen height won't work well if we dynamically change the zoom (something we want to do in the future). We really should be placing the camera / puck in reference to the bottom sheet (out of scope for this PR but just noting).

Doubling target distance seemed to work pretty well, testing on a 4 different devices with varying screen densities and sizes. For the sake of the zoom bump, this looks like something we can do for now until we figure out a better way to address the target distance.

[danesfeder]

@sarahlensing this looks good to go on our end. If you want to write those tests prior to merging, please feel free :)

@ericrwolfe I'll address the target distance adjustments in a new PR (most likely the one in regard to a more dynamic camera)

[danesfeder]

@sarahlensing I'm going to go ahead and merge this, as we are looking to build off of it for the rest of the dynamic camera work. I cut a ticket to track the test integration #678