Support transitive virtual library implementations

[tek]

Given an executable E that depends on library A which depends on a virtual library implementation B, the modules in E appear to require B in their dependencies, but this doesn't happen with the current resolver.

[mobileink]

By "virtual library" you mean what dune describes in https://dune.readthedocs.io/en/stable/variants.html ?

And by "current resolver" you mean codept?

Note that this distinction between virtual and non-virtual ("real"?) libraries is not necessary (IMHO). I have not yet worked out the details of how to translate dune's virtual_modules, implements, default_implementation etc. to OBazl, but I know I do not want to introduce the term "virtual". I think it just adds an unnecessary layer of (conceptual) complexity. We already have signatures, structures, and select that should be enough. I think.

[tek]

By "virtual library" you mean what dune describes in https://dune.readthedocs.io/en/stable/variants.html ?

yes

And by "current resolver" you mean codept?

no, I mean the dependency resolver of Gazelle, which finds the package a locally depended upon library is defined in

Note that this distinction between virtual and non-virtual ("real"?) libraries is not necessary (IMHO). I have not yet worked out the details of how to translate dune's virtual_modules, implements, default_implementation etc. to OBazl, but I know I do not want to introduce the term "virtual".

I introduced this concept here to mirror the behaviour of dune's virtual modules. The dificulties with this pattern include a hash mismatch for the interface file (which is generated for the implementation when no connection is made to the virtual interface, and can be mitigated with the -intf-suffix .ml option), and that a namespaced library will create the module as Impl__Mod instead of Virt__Mod, where the latter is what consumers of the virtual library depend upon.

If you manage to implement this feature without introducing a new concept, it would surely be preferable.