Add dune.2.9.0

[abbysmal]

After investigating the hanging of the coq build with Multicore OCaml, under some specific scenario, it turns out updating dune to 2.9.0 fixes the issue.
This specific hang is still a bit of a mystery to me, but it seems like the failure to build coq with Multicore triggers a loop in a retry mechanism in dune's fibers.

I also noticed that we still have a system dune in place to work around past compatibility issues with 4.09.0 and Multicore not being able to build dune by itself.

It does seems the dune version used by the sandmark run is indeed the one installed in the switch. (and not the system dune)

I was wondering if there was a reason why we still have the system dune setup active in sandmark? I assume it is still useful for trunk (since dune may break against trunk), however Multicore+dune compatibility is not an issue anymore.

[kayceesrk]

@shakthimaan please can you take a look at this?

Also,

I also noticed that we still have a system dune in place to work around past compatibility issues with 4.09.0 and Multicore not being able to build dune by itself.

We shouldn't need to hardwire system dune anymore.

[shakthimaan]

Multicore+dune compatibility is not an issue anymore.

Yes. The sys_dune_hack has been removed in the 2.0.0-alpha branch.
Source: https://github.com/shakthimaan/sandmark/blob/2.0.0-alpha%2B001/Makefile

We are still blocked on dune.2.8 as we require the Irmin benchmarks to be built.
#230

[kayceesrk]

We should retain the system dune hack since dune is not known to reliable build on trunk. This will break the entire benchmarking setup for trunk if dune fails to build on trunk.

[shakthimaan]

Sandmark has been updated to use dune.2.9.0 with the following merge #251, making this PR redundant. Hence, closing the same.