RFC: Manage duniverse manual

[Leonidas-from-XIV]

We discussed what the preferable way was but haven't written it down in an comprehensive way so that users understand the Pros and Cons of each solution.

This PR adds a new page to the manual to discuss what we think is the best way to run opam-monorepo and how to deal with the caveats.

Suggestions welcome!

[samoht]

I do not agree: there are valid use-cases for committing vendor code to the repositories, let's not try to dictate their requirements to our users. Would be much better to just reckon this, and point to possible issues and fixes (as the next paragraph does well).

[avsm]

Indeed, irrespective of the recommendations of the opam-monorepo maintainers, I am going to continue checking in my code into duniverse/ :-) The reason for this is that the benefit of this approach is somewhat understated and hidden away:

The repository can be immediately used after cloning as everything is self-contained

The above is an absolutely massive benefit for newcomers to a project:

• it doesn't require opam to be installed, and, more crucially, doesn't require a working opam init to have happened.
• only dune is required for a build, and (since dune 2.0) the dune binary can be distributed independently of the dune libraries (which are vendored). Thus a newcomer can apt install ocaml-dune and get on with things.
• it doesn't require opam-monorepo to remain working into the future. I can git checkout an older revision of RWO and have a reasonable expectation that it'll build, for example.

This guide is an excellent start, but it is organised around "operational" uses of monorepo. But a reader of the document unfamiliar with opam-monorepo is going to start from a different mindset: they are going to wonder how best to serve various users of their projects and achieve outcomes such as "distribute this binary for people that don't know ocaml", to "make first contribution to the core tool", to "experienced user wants to patch a library and upstream the change".

If you organise things by "how deeply someone wants to get into the project", then the ordering of how you introduce vendoring, lockfiles and on-the-fly locking changes.

[NathanReb]

It looks good! Overall I think it can be simplified a little a bit, some sections are very similar between the two main workflows and can likely be merged.

[NathanReb]

This items and the next one are advantages tied to the use of opam-monorepo itself and are common to the two described workflows.

We can probably remove them from here, eventually moving them elsewhere in the manual.

[NathanReb]

At the moment I would advise that users modify the content of the duniverse to experiment quickly and once they're happy with the result, extract a patch, either to upstream the changes or to a fork of theirs.
At that point they can use pin-depends fields to let opam-monorepo know to use this instead of upstream. It makes it easier to deal with updates.

We will need to better support this in the future of course but it might be worth suggesting this workflow here as well.

It also closes the gap between the two proposed approaches as you don't necessarily have to version the duniverse/ to achieve this.