Comparison of MathTransforms should use ContextualParameter

Use case (assuming SIS-433 is not yet fixed): Let A = CRS.forCode("EPSG::29871) and B = A formatted in WKT and parsed back. Compare those two CRS. Because of the slight difference in "British chain (Sears 1922)" unit definition described in SIS-433, we get slightly different "Easting at projection centre" parameter value after their conversion to metres (parameter value before conversion is 29352.4763 chSe):

A easting = 590476.8714630401 metres
B easting = 590476.8714630402 metres

Apache SIS implementation splits map projections in normalization → projection on normalized ellipsoid → denormalization steps. The denormalization matrices are:

A:
┌                                                              ┐
│  3813171.507859623  5084228.678431943  -0.003883839275807552 │
│ -5084228.678431943  3813171.507859623  -0.003303801804941493 │
│        0                  0             1                    │
└                                                              ┘
B:
┌                                                              ┐
│  3813171.507859623  5084228.678431943  -0.003883839175807552 │
│ -5084228.678431943  3813171.507859623  -0.003303801804941493 │
│        0                  0             1                    │
└                                                              ┘

Those matrices are almost identical. They differ only in their m02 terms, copied below. The easting parameter is also shown for comparison purpose (reminder: this parameter differs in the last digit between the two CRS):

A:            -0.003883839275807552
B:            -0.003883839175807552
Easting = 590476.8714630401 metres

The problem is that while the difference has its origin in the last digit of a map projection parameter, its effect in the denormalization matrix appears in the middle of a term. The relative error (A-B)/A is about 2.6E-8, which well above the 1E-13 tolerance threshold currently used for matrix comparisons. We can not just relax the tolerance threshold since whether the difference is relevant or not depends on the operations performed before to add this term.

For fixing this issue, comparison of MathTransform instances should use the information provided in ContextualParameters when those information are available. It would allow to compare the original easting parameters (with a difference only in the last digit) instead than the transformed value in denormalization matrix.

Testing and debugging

In core/sis-referencing/src/test/java/org/apache/sis/test/integration/ConsistencyTest.java, put a @Test annotation on the debug() method and temporarily disable other tests. Put a breakpoint on the following line of code around line 273:

assertTrue(urn, Utilities.deepEquals(crs, parsed, ComparisonMode.DEBUG));

After execution reaches this point, jump to ConcatenatedTransform.equals(Object, ComparisonMode). This method will be invoked indirectly by AbstractCoordinateOperation. Proposed fix is to add the following step: if deepEquals(getSteps(), … returns false and ComparisonMode.isApproximative() returns true, then compare again using the pseudo-steps. This may require verifying the equals implementation of temporary objects created in those pseudo-steps.