Set C++ standard to 20 for dune-common >= 2.11

[SoilRos]

This change ensures that the C++ standard is set to 20 when using dune-common version 2.11 or greater. The reasoning is that (the soon to be released) dune 2.11 will require mandatory C++20.

Note that this requires OPM/opm-simulators#6518 for smooth transition into C++20 later on.

Close #4775

[blattms]

jenkins build this please

[blattms]

OK, this is a bit strange. There should be exactly 0 changes when using DUNE 2.10, yet we have a failing test (mpi.compareECLFiles_flow+UDQ-01 with

Unified restart files, sequence  11

Comparing SEQNUM ...  done.
Comparing INTEHEAD ...  done.
Comparing LOGIHEAD ...  done.
Comparing DOUBHEAD ...  done.
Comparing IGRP ...  done.
Comparing SGRP ...  done.
Comparing XGRP ...  done.
Comparing ZGRP ...  done.
Comparing IWEL ...  done.
Comparing SWEL ...  done.
Comparing XWEL ...  done.
Comparing ZWEL ...  done.
Comparing ZWLS ...  done.
Comparing IWLS ...  done.
Comparing ICON ...  done.
Comparing SCON ...  done.
Comparing XCON ...  done.
Comparing IACT ...  done.
Comparing SACT ... 

Keyword: SACT, origin Restart, sequence 11

Value index                 = 4
(first value, second value) = (14.1, 14.1417)

Program threw an exception: [/var/lib/jenkins/post-builder/workspace/opm-common-PR-builder/test_util/EclRegressionTest.cpp:227] Deviations exceed tolerances.
The absolute deviation is 0.04166603088378906, and the tolerance limit is 0.02.
The relative deviation is 0.0029463310524275635, and the tolerance limit is 1e-05.
Comparing '/var/lib/jenkins/post-builder/workspace/opm-common-PR-builder/deps/opm-tests/actionx/opm-simulation-reference/flow/UDQ-01' to '/var/lib/jenkins/post-builder/workspace/opm-common-PR-builder/mpi/build-opm-simulators/tests/results/flow+udq-01/UDQ-01'.

Could be a race condition because between merges in opm-tests and another module, but there is nothing in opm-tests.

[blattms]

jenkins build this please

[SoilRos]

I just double checked that C++20 is not being set when DUNE is lower than 2.11 (CMake conditionals are some times picky). So I don't think it comes from this PR either.

[bska]

Keyword: SACT, origin Restart, sequence 11

Value index                 = 4
(first value, second value) = (14.1, 14.1417)

For what it's worth, SACT[4] is the time in output units–here days–at which the action was last triggered. If the PR, for whatever reason, causes the model's time stepping sequence to be slightly different from the reference then it's not unreasonable that that would manifest as a change to SACT[4].

[blattms]

Thanks @bska. I'll check the two jenkins runs. The second one succeeded 😬

Admittedly, I am a bit worried about this, but also quite sure that it cannot be from this PR.