Dependency tracking is still a mess.

[dbuenzli]

Dependency tracking and handling is still a mess if not wrong, both conceptually and in the implementation (especially). We need to go back the drawing board.

One example is the current description of the assemblage tool itself here. This description is wrong because the tool unit doesn't specify that it depends on cmdliner, the fact that this description works relies on the fact that lib depends itself on cmdliner, but stricto sensu nothing tells us that this is only an internal use by the library. Would lib drop that dependency in the future, the description would no longer work, this means that the tool unit is underspecified.

We need to:

1. Write the documentation about how dependencies are tracked/what is expected to be written and what they mean according to their phase.
2. Translate the documentation of 1. into to a very clear semantics to indicate what constitue dependencies and their closure (semantics of Component.{dep,closure}), (should these function depend on the phase ?)
3. Review and principle the flag generation procedure, currently things are scattered in As_project, As_project_makefile and As_resolver. I have the impression that each component should always only define its flags and that the ?all argument in As_project should die. The behaviour of ?all should happen in As_project_makefile as this allows backend to decide how dependencies should be treated and composed (e.g. by defining intermediate variables).

[dbuenzli]

What I said above about the tool unit is wrong (it doesn't depend on cmdliner, the same comment applies though mutatis mutandis to ctypes_gen.