fix: fix bug in CtLineElementComparator

[MartinWitt]

Core Problem

As we saw in issue #3514 analyzing Palladio-SimuLizar produces jdk erros while sorting.
The reason for this is because the CtLineComparator does not follow the compareTo contract. This patch fixes the comparator.

Some Math Stuff

A comparator must follow the compareTo contract in java. The compareTo contract defines two formulas:

(1) antisymmetric sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
(2) transitive (x.compareTo(y)>0 && y.compareTo(z)>0) => x.compareTo(z)>0

Assuming we have 3 points X,Y and Z and all points have invalid positions.

compareTo(X,Y) == -1 ==> X < Y
compareTo(Y,Z) == -1 ==> Y < Z
compareTo(X,Z) == -1 ==> X < Z
Looks good till here but now:
compareTo(Z,X) == -1 => Z<X
here we violate the transitive requirement. Because Z is now less than X.
If we do the same after the change:
compareTo(X,Y) == 0 ==> X=Y
compareTo(Y,Z) == 0 ==> Y=Z
compareTo(X,Z) == 0 ==> X=Z
compareTo(Z,X) == 0 ==> Z=X
The change still follows the antisymmetric contract, because sign(0)=0== -sign(0).

Consequences

Some testcases relay on the old sorting, because order was different. Some refactoring for the testcases is needed.
There is a risk, that some users have problems with new correct ordering.

[monperrus]

Thanks for the fix!

2 failing tests are on generated code, we just have to regenerate the code.

So only CtClassTest.getConstructor is really failing, which suggests that we won't break many things.

Overall, the fix is reasonable to me.

[MartinWitt]

@monperrus merge/review ping

[monperrus]

thanks a lot for the update, see comment.

[monperrus]

Thanks a lot Martin!