New opam release

[Firobe]

We should:

• update the current version package with a dune < 3 constraint
• release a new opam version of the orun package that includes the now merged refactor: move binary to own dir #4 PR without that constraint, e.g. that can be used by sandmark without needing pins

[ElectreAAS]

@shakthimaan I assigned this issue to you so we can avoid another specific pin in sandmark, and just use the latest opam version

[shakthimaan]

update the current version package with a dune < 3 constraint

Now that we are using dune.3.5.0 for 5.1.0+trunk, the constraint is no longer required?

[Firobe]

The problem was:

• the package currently released on opam breaks if using a dune version > 3. No matter what we should push a revision for that version to forbid dune > 3 so that opam rejects that version when a newer dune is installed
• there is no release on opam for the current development version, so a pin is needed for sandmark. To avoid that, the current dev branch should be released as a new version of the opam package

I don't think the usage of dune 3 in sandmark changes that, but these are pretty minor problems if sandmark is the only place where orun is used.