Unwrap LatLngBounds for the shortest path when requesting camera

[LukasPaczos]

Closes #11733.
Refs. #11758.

[tobrun]

is this javadoc intended?

[tobrun]

same as above

[tobrun]

same as above

[osana]

I think it might be cleaner to have two versions of LatLngBounds:

LatLongBoundsUnwrapped :
east >= west (always) , longitude can be any value
that is what maps-gl-native apis expect

LatLongBound (wrapped):
longitude is between -180 and 180, east < west when crossing IDL
that is what Android users expect

At the moment we try to mix the two concepts together

cc @tobrun, @LukasPaczos

[LukasPaczos]

To make the LatLngBounds class consistent, I'd rather aim for the LatLngBounds#Builder and LatLngBounds#from to return wrapped values (as the Android users expect) and we can unwrap them with LatLngBounds#unwrapBounds util method introduced in this PR before we push it to the other APIs. This also lets user unwrap them if that's needed for any internal operations. I feel like introducing another object is too much here.
What do you think @osana?

[osana]

I can live with it but here is what bothers me most:
unwrapBound() being a public method (I understand that it is that way to use if from MapboxMap)

That means that even though we are saying that our LatLngBounds do not wrap and all values will be stored as wrapped,

we then allow to do:

LatLngBounds latLngBounds = LatLngBounds.from(10, -170, -10, 170).unwrappedBounds();

Now we have latLngBounds.getNorthEast().getLongitude() return 190

(that contradicts our intent to have longitude be between -180, 180). Now this instance of LatLngBounds could be passed around and the notion that bounds were just unwrapped would be lost. Of course, you can get longitude() and compare agains 180..

You can see that more testing will need to be added so that two unwrapped bounds and unwrapped & wrapped bounds produce correct union(), span(), center() etc.

[LukasPaczos]

We can document the LatLngBounds#unwrapBounds method as internal only and add additional javadoc notes that LatLngBounds operates on wrapped values only, or even move it to the Utils class so that it's not reachable from the LatLngBounds class itself. Do you think that would be enough?

[osana]

Adding docs is always good.
Making union() and intersects() work with both wrapped and unwrapped state bounds would be good.

There are several more APIs in gl-native that use LatLngBounds like Snapshotter.
We need to check what happens when we pass bounds going over antimeridian.