Fix: merge multiple identical opam pins on a local package

[ElectreAAS]

Fixes #12990

Commit 1 expands the test
Commit 2 fixes one bug, but there is remaining weirdness going on
Commit 3 is just what felt to me like a readibility improvement, completely optional deleted as not wanted

[ElectreAAS]

This looks very dubious to me, especially since there is this comment in a related test:

dune/test/blackbox-tests/test-cases/pkg/pin-stanza/mixed-opam-dune.t

Lines 1 to 2 in 4cc2b86

	We try to use a project that has both opam files and a dune-project file. We
	should favor the dune metadata in such a case.

[Leonidas-from-XIV]

Yes, this is quite dubious. I would say if the versions disagree we should error and not pick sides, to be consistent with how it works when it is pinned twice via dune.

But this isn't introduced by this code, right? In such case it could be fixed in a separate PR.

[ElectreAAS]

Indeed this wasn't introduced by this PR, it was already present behaviour

[rgrinberg]

Why is it dubious? This is exactly what we do everywhere else. The opam pins are there for opam users presumably.

[ElectreAAS]

Usability note: the bug was discovered while trying to build irmin, and I can confirm that with this patch irmin builds correctly!

[rgrinberg]

The errors seem to be non deterministic? Perhaps you need to sort them?

[Leonidas-from-XIV]

I think the code is fine, the main question is whether that dubious behavior comes from this PR or not.

[Leonidas-from-XIV]

Yes, this is quite dubious. I would say if the versions disagree we should error and not pick sides, to be consistent with how it works when it is pinned twice via dune.

But this isn't introduced by this code, right? In such case it could be fixed in a separate PR.

[Leonidas-from-XIV]

Which is? It seems a bit odd to defer to another test, especially given the tests evolve separately.