Improvement on Antimeridian handling logic

What is the background?

The basic assumption on ISCE3 for antimeridian handling is that the width of a bounding box is no larger than 180 degrees in geographic coordinates. Let's say we have a case that [MinX, MaxX] = [-178, 178]. The difference between MaxX MinX is 356, which is larger than 180. As if violates the "180-degree" assumption, therefore the current antimeridian handling logic recognized MinX as East, and MaxX is West. In other words, [West, East] = [178, -178]. Wrapping them to [0, 360] becomes [178, 182] that satisfies the maximum longitudinal length.

What is the issue?

The internal PR discussion for #104 has raised a concern about the uni-intuitiveness of about which of MinX and MaxX are on west and east boundary respectively, which can be an issue when a polygon or bounding box crosses antimeridian. The "wrapping" routine do exist throughout the code, but they are rather scattered, and we need a better structure to handle the antimeridian handling logic.

Suggested solution

@gmgunter has suggested the antimeridian handling strategy as below to improve ISCE3:

• Add a wrapper for Perimeter::getEnvelope() similar to this wrapper for BoundingBox::Merge() that takes care of unwrapping discontinuities at the antimeridian and swapping the endpoints so that MinX is always the left edge and MaxX is always the right edge.
• Add documentation to BoundingBox that clarifies that MinX is always the left edge and MaxX is always the right edge, and MinX <= MaxX.
• Remove the kludge from getGeoBoundingBox(), _addMarginToBoundingBox(), and BoundingBox::Merge() that exists to work around this issue with Perimeter::getEnvelope().