feat(describe): include module origin in describe workspace

[NatKarmios]

Add an origin field to each module reported by dune describe workspace output, indicating whether its source was written by hand (source), generated by a rule stanza (dune, with the generating dune file and the rule's dependencies), produced by ocamllex, ocamlyacc, or menhir, or synthesised by dune itself for wrapping (wrapper). Generated modules point at the responsible file.

To illustrate:

(modules
 (((name Plain)     ... (origin source))
  ((name Lexer)     ... (origin (ocamllex path/to/lexer.mll)))
  ((name Gram)      ... (origin (ocamlyacc path/to/gram.mly)))
  ((name Parser)    ... (origin (menhir path/to/parser.mly)))
  ((name Generated) ... (origin (dune ((dune_file path/to/dune)
                                       (deps (_build/default/dep.txt))))))
  ((name Mylib)     ... (origin (wrapper path/to/dune)))))

Fixes #12998

Notes:

• Parser-generated modules are queried from Ml_sources, exposed via a new parser_gen_origins function
• Rule-generated modules report the rule's expanded file dependencies via Reflection.evaluate_rule (globs and aliases are resolved to concrete files, matching dune rules).
• The deps under a dune origin are always shown, regardless of whether --with-deps was used; I believe this is desirable as a rule's dependencies are a separate concern from inter-module dependencies
• Drive-by: Tweak the docstring for Reflection.Rule.expanded_deps; it claims that glob listings are skipped, but it appears that expanded_deps includes the files that the relevant globs resolve to

[rgrinberg]

The code looks fine, but can we get a confirmation that we have a potential user for this? I know you picked this up from an open issue, but users often change their mind, or realize that they need something slightly different than what they've asked for originally. Would be good to know for certain that this field will be made user of.

[rgrinberg]

This field can potentially be huge. I'd rather that we'd:

1. confirm that we need it for something
2. guard emitting behind a flag

[NatKarmios]

I wonder whether it would be preferable to guard the entire origin field behind a flag, or just the file dependencies for a dune origin.

[rgrinberg]

Well, I'd try to emit the dependencies completely if possible. They can be really huge and users shouldn't be just fetching all of them like this. It should be done on demand per rule if possible. I would even confirm that this dependencies field is needed at all. If all you want this field is to support sources being copied, you could try to special case that.

Separately, the origin field can be guarded behind a flag, but it's not mandatory to do this. Take your pick here.

[NatKarmios]

The code looks fine, but can we get a confirmation that we have a potential user for this? I know you picked this up from an open issue, but users often change their mind, or realize that they need something slightly different than what they've asked for originally. Would be good to know for certain that this field will be made user of.

Thanks for the response—to introduce myself, I'm Nat, a new intern at Ahrefs (pleasure to meet you 🙂). I'm looking into observability, measurability and performance of Dune, and thought this would be a good place to start.
I can confirm that folks at Ahrefs are still interested in this change.

[raphael-proust]

but users often change their mind, or realize that they need something slightly different than what they've asked for originally

as the person who opened #12998 (comment) i'm still interested in this both from a practical pov as well as a theoretical/moral one (mly mll are as much part of an ocaml project as ml and mli).