OCAMLPATH value when ocamlfind is vendored

Hi,

While testing #3956 we noticed some strange behavior when ocamlfind is part of the workspace. The exact issue is described at
https://github.com/NathanReb/test-new-mdx-stanza.

After debugging with @NathanReb, it seems that the core of the issue is how OCAMLPATH is set by dune. This variable defines where ocamlfind looks for packages (or something related to that question). In a pure opam context, opam-switch/lib seems to be correct. dune sets it to _build/install/default/lib which corresponds to the "compiled version of the dune workspace".

https://github.com/ocaml/dune/blob/6095f6fbf58ea44248703a612f0de9edff092150/src/dune_rules/context.ml#L578

The question is how can an ocamlfind that is part of the workspace access packages installed in a local opam switch?

In https://github.com/realworldocaml/book, we were not seeing any issues because the mdx stanzas have a dependency on (package mdx) and so everything was copied under _build/install/default/lib. In the minimum working example above, it is possible to "fix" the test by adding (deps (package findlib)) which copies all the findlib definitions at the place where findlib will look for them, but it seems that it should not be necessary.

I tried adding default_ocamlpath (as defined above - in the opam2 situation it's opam-switch/lib) to OCAMLPATH:

https://github.com/ocaml/dune/blob/6095f6fbf58ea44248703a612f0de9edff092150/src/dune_rules/context.ml#L528

This fixes the mdx situation but I'm not sure it's the right one.

What do you think @jeremiedimino @rgrinberg @bobot ?

Reproduce the behavior with the linked test-new-mdx-stanza workspace, then inspect src/dune_rules/context.ml around lines 528 and 578 where default_ocamlpath and OCAMLPATH are set. Compare the vendored ocamlfind case with a local opam switch and the workaround using (deps (package findlib)). Done means the intended OCAMLPATH behavior is established and the reported workspace scenario works without that workaround.