Update CSV-compare tool to version 2.1.0

[casella]

We just released version 2.1.0 of CSV-compare. This has two new important features to avoid false negative, that we discussed in the MAP-Lib group:

• avoid too narrow tubes for near-zero variables
• correctly compare long simulations to short reference results (poor man's solution for testing chaotic systems while we get an agreement on Define a verificationExperiment annotation for experiments meant to compare results for regression testing and cross-tool comparisons modelica/ModelicaSpecification#3473)

We should update our CI to use this new version, so we avoid false negative in the verification results. This should be done ASAP, so we can do the regression testing for 4.1.0 before we tag the RC version mid-October

[adrpo]

Currently we have the C# code translated to the C code at: https://github.com/OpenModelica/OpenModelica/blob/master/OMCompiler/Compiler/runtime/SimulationResultsCmpTubes.c
so we would need to update that.

@sjoelund: would it be possible to use mono and run the C# tool to do the diff. I know, is yet another dependency for the testing suite.

[sjoelund]

It might be, but the diff tool at least when I translated it didn't have any interface to get the curves and create our own output. It was just those very large reports of multiple HTML files that were produced. You even need to parse the HTML to see if it succeeded or not IIRC.

The other problem is it might need to be adapted to Linux as well. It had hard-coded \\ for path separators, etc instead of using joinpath-style code.

It is anyway not a hard dependency, but a Suggests or something for Ubuntu, so it wouldn't need to be installed by everyone.

[casella]

I think fixing the first issue on the existing codebase (the tube widths) is a no brainer. Thomas applied some refactoring to the C# source code, but I guess it's not really necessary to do that, we just need to change 1e-12 to 1e-3 in a couple places.

The second issue is a bit harder, I understand the fix by Thomas was non-trivial. Eventually, when we introduce proper annotations to specify a shorter StopTime for verification, it won't be necessary anymore.

Maybe I can try the first fix myself, then we see what happens?