Test bug RE assertIntersect and non-normalized rectangles

I got this failure:

Tests run: 100, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.437 sec <<< FAILURE! - in org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest
testGeoLongitude { seed=[859E55631A6DA980:F0F85AA453DFE02B]}(org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest)  Time elapsed: 0.016 sec  <<< FAILURE!
java.lang.AssertionError: Rect(minX=180.0,maxX=180.0,minY=-90.0,maxY=60.0) intersect Rect(minX=-180.0,maxX=-180.0,minY=-90.0,maxY=60.0) expected:<Rect(minX=180.0,maxX=180.0,minY=-90.0,maxY=60.0)> but was:<Rect(minX=-180.0,maxX=-180.0,minY=-90.0,maxY=60.0)>
    at __randomizedtesting.SeedInfo.seed([859E55631A6DA980:F0F85AA453DFE02B]:0)
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:118)
    at org.locationtech.spatial4j.shape.RandomizedShapeTest._assertIntersect(RandomizedShapeTest.java:151)
    at org.locationtech.spatial4j.shape.RandomizedShapeTest.assertRelation(RandomizedShapeTest.java:141)
    at org.locationtech.spatial4j.shape.RandomizedShapeTest.assertRelation(RandomizedShapeTest.java:135)
    at org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest.testGeoLongitude(BBoxCalculatorTest.java:61)

These are two rectangles that are vertical lines along the dateline, but one of them is defined with -180 and the other with +180. They are otherwise equal (same latitude range). But they don't report themselves as equal.

If we normalized zero-width rectangles at construction then we wouldn't have this problem. That's one way to fix, though loses the input coordinates as given and I'm not sure if that matters?

Alternatively, assertIntersect could be smarter to try and detect this. It already detects rectangles that are actually degenerate points at the pole. That could have been handled via rectangle normalization as well (zero height rects at the pole could have their longitudes normalized, to say, 0,0). Given this precedent, I guess we could continue with it and have assertIntersects detect this scenario. I'm inclined to go with that as it's least risky (will impact nobody; just updating a test to not fail).

Review RandomizedShapeTest._assertIntersect and BBoxCalculatorTest.testGeoLongitude, then reproduce the reported failure involving vertical rectangles at -180 and +180. Check the existing handling for degenerate polar points before choosing an approach. Done means the dateline case passes without breaking the surrounding intersection assertions.