Add equals/hashCode consistent with compareTo for value-semantics Comparable classes

[grootstebozewolf]

Several JTS classes implement Comparable with a meaningful compareTo() but do not override equals(), so two objects that compareTo() orders as equal (returns 0) are not equal by equals(). This violates the recommended consistency between compareTo and equals, and means the affected types misbehave as keys in hash-based collections.

Add equals() and hashCode() to the classes whose compareTo defines a genuine value equality, defining equals() as (compareTo == 0) so the relation holds by construction, with hashCode() over the same fields.

Changes Made:

• LinearLocation — (componentIndex, segmentIndex, segmentFraction).
• EdgeIntersection — (segmentIndex, dist).
• NodeSection — (isA, dim, id, ringId, v0, v1).
• OrientedCoordinateArray — points walked in canonical orientation order, so an array and its reverse (which compare equal) hash equally.
• Add consistency tests for each updated class (equals/compareTo agreement, the equals/hashCode contract, and orientation-independence for OrientedCoordinateArray).
• Update history.

The remaining Comparable classes (BoundablePair, EdgeEnd, Corner, SweepLineEvent, OffsetCurveSection, …) use compareTo as a sort or priority ordering keyed on a subset of state, where compareTo == 0 does not imply object identity (e.g. BoundablePair orders by distance only). Aligning equals there would conflate distinct objects, so they are intentionally left unchanged, as the Comparable contract permits.

Fixes#1184