Enable alleyPriority for automobile routing

[1ec5]

The RouteOptions.alleyPriority property now works with DirectionsProfileIdentifier.automobile in addition to DirectionsProfileIdentifier.walking.

/cc @mapbox/navigation-ios @avi-c

[1ec5]

Until this PR lands, or in v0.38, you can work around the lack of alley priority support while driving by subclassing RouteOptions and overriding urlQueryItems to add an alley_bias query item.

[1ec5]

DirectionsTests.testGETRequest() and DirectionsTests.testPOSTRequest() are failing in several ways. The cascading failures start with:

/Users/distiller/project/Tests/MapboxDirectionsTests/DirectionsTests.swift:54: error: -[MapboxDirectionsTests.DirectionsTests testGETRequest] : XCTAssertLessThanOrEqual failed: ("8200") is greater than ("8192") - maximumCoordinateCount is too high

Now that the alley_bias query parameter is included in the request URL by default for the driving profile, slightly fewer coordinate pairs can fit in the URL for a GET request.

[avi-c]

These changes look good to me aside from fixing the tests.

[1ec5]

I’ve updated the tests.

[Udumft]

Maybe with this change it now make sense to set alleyPriority to .low by default if current profile is .automobile?
It alters current behavior, but maybe that is what we wanted with this change?

[1ec5]

I think the application or maybe the navigation SDK should be responsible for making that decision. As much as possible, MapboxDirections should align with the Directions API defaults. But the navigation SDK does vend a NavigationRouteOptions subclass that could set the alleyPriority to .low for .automobile.