fix: run ocamldep for single-module stanzas (#4572)

[robinbb]

Run ocamldep for single-module stanzas so that per-module library dependency
filtering works for all stanza sizes.

Dune previously skipped ocamldep for singleton stanzas as an optimization
(no intra-stanza deps to compute). This prevented the per-module filtering
in #14021 from working, since it relies on ocamldep output to determine
which libraries a module references. Without the data, single-module
stanzas fall back to all-library glob deps via the can_filter guard
(the dummy dep graph has dir = Path.Build.root, which doesn't match
Obj_dir.dir). Correctness is maintained, but the optimization doesn't
apply.

Removing the singleton shortcut enables filtering for single-module stanzas.
The cost is negligible: one extra ocamldep invocation per single-module stanza.

Depends on #14021.
Ref: #4572

[rgrinberg]

I don't quite get the motivation behind this PR. It might be true that this optimization does not fire for single module libraries, but consider the case where it might fire: there must be libraries referenced in libraries that are not present in the only source file. Thus, those libraries are just unused and can be removed from the libraries field altogether. Conveniently, we already have a check to detect unused libraries. I suppose we can introduce a warning here as well?

[robinbb]

Thanks for the feedback @rgrinberg. I think the value here might be different
from what the PR description conveyed, so let me clarify.

The scenario in the test isn't about unused libraries — it's about unused
modules within a used library. The consumer uses_alpha genuinely depends on
base_lib and references Alpha. But base_lib also contains Unused, and
modifying Unused's interface triggers recompilation of uses_alpha even
though uses_alpha never references Unused.

@unused-libs wouldn't flag this because the library IS used — the consumer
references one of its modules. The issue is that changing a different module
in the same library causes unnecessary recompilation. This is the core problem
described in #4572 for unwrapped libraries: per-module granularity within a
library dependency.

For multi-module stanzas, #14021 already handles this — the per-module
filtering reads ocamldep output and declares deps only on the specific library
modules each stanza module references. But for single-module stanzas, dune
skips ocamldep entirely (the singleton optimization in dep_rules.ml),
producing no .d files. Without ocamldep data, the filtering falls back to
glob deps on the entire library, and changing any module in the library
triggers recompilation.

Removing the singleton shortcut makes ocamldep run for all stanzas, giving
the filtering the data it needs. The cost is one extra ocamldep invocation per
single-module stanza — negligible compared to the compilation it avoids.

Let me know if I have misunderstood.

[rgrinberg]

I see. I guess this is relevant whenever there's a singleton library using another library that has (wrapped false). In such a case, running ocamldep is still beneficial because we might depend on a subset of the entry modules in that library.

[rgrinberg]

If you prefer, you could also move this commit to the top of your chain. I think it can be merged without much scrutiny.

Finally, I believe this also changes how we build single module executables? I don't think we ran ocamldep for them before, but a test to confirm this or the contrary would be useful. I'm less excited about dropping this optimization for such single module executables. The compilation and linking are fused into a single command for single module executables, so this optimization can never correctly fire anyway.

[robinbb]

Superseded by #14103, which is based on upstream/main (independent of #14021). The baseline test documents current behavior, and the code change is the same.