[WIP] Unified module handling

[rgrinberg]

This PR has a few seemingly separate goals, but they are quite tricky to separate into their own PR's. So instead of spending more time into splitting this into logical chunks, I will try to get it all in at once:

• Introduce Modules.t as the central type for holding module layout information. This type will allow us to develop several new features on top of it. Examples include: qualified subdirs, name mangling for executables.

• Replace Lib_modules by Modules.t wherever possible. Whatever use cases remain, can be replaced by Modules.Lib.

• Use the same dependency graph in a compilation context for all modules. Previously, we'd try to be a little too clever for our own good and use specialized graphs for wrapped compat/alias modules. This is too hard to track in one's head once we have a combinatorial explosion of wrapped compat, vlib, implementations, qualified subdirs.

• Use a combined module representation for implementations of virtual libraries. This will greatly simplify the dependency handling for virtual libraries and replace a few weird looking use cases of Vimpl.

• Fix dependency graph for wrapped compat modules. Previously, those would always depend on the module they replace. That's not really correct, as those modules must be go through the lib interface module.

• Simplify interpretations of ocamlobjinfo deps. Now the compilation units are just looked up directly. There's no need to splice module names.

• Remove copying code for virtual library implementations. The non copying approach is far simpler to implement with this scheme. We can store a bit of information for every module such as from : Vlib | Impl and extend the Obj_dir.t type to allow for a Impl of { vlib : t ; impl : t } constructor.

• Make stdlib a different layout in Modules.t. Currently, this is being special cased in many places of the codebase. Yes, this is quite a special case, but we might as well add first class support for the compiler and the stdlib

• Refactor building alias modules outside of lib_rules. We'd like this functionality to be available for executables as well. This is also a pre-requesite for the stdlib stuff to work.

One thing that this PR made me realize is that virtual libraries with wrapped_compat are basically broken. This means that it's going to be quite difficult to transition unwrapped vlibs to wrapped mode. @avsm @TheLortex is this a problem in practice? It should be possible to fix after this PR.

[rgrinberg]

@emillon think you can give this an initial review while Jeremie is away? The point of this PR is to simplify a bunch of things, so hopefully it should be accessible to all contributors. There are some rough edges that need polish, but the main interface is established.

[emillon]

There's a lot going on so it's a bit difficult for me to review but this looks like a useful abstraction to have.

[rgrinberg]

The latest commit changes the format of the dune-package file. This only works well if dune is not a {build} dependency of packages.

[rgrinberg]

I'm thinking that we'll need a new interface for accessing the alias module of other modules. Something like:

val alias_module : Modules.t -> Module.t -> Module.t option

This will allow us to have unified interface stdlib, wrapped, and qualified subdirs.

[rgrinberg]

To make it easier on reviewers, I've put some effort into splitting this PR after all. The change to simplify reading ocamlobjinfo deps has already been merged. Now, I will extract the minimum required to fix the dependency graph for wrapped compat modules.

[ghost]

Thanks, making review easy is important :)