feat: let extensions generate opam constraints

[emillon]

This adds a new feature where extensions can generate opam dependencies. For
example, (using mdx x.y) will include mdx as an opam dependency.

TODO:

• document interface
• update menhir and link to relevant issue
• update ctypes
• check if other extensions need to be updated
• changelog

[emillon]

@rgrinberg, before I go further, does that approach look sensible?

[rgrinberg]

The idea itself seems fine. However, I'm wondering if the implementation is flexible enough. In particular, what if the extension is used only for the test suite? How would I make sure the generated constraint has with-test.

[emillon]

The approach of the current implementation is to back off if the package appears in the package's dependencies in dune-project. The idea is that we try to provide good defaults (mdx would be with-test; ctypes and menhir would not), but we trust that the user will have the last word.

An alternative would be to add more precise knobs when parsing the (using) directive (there's already a hook for this used in fmt): (using mdx (opam with-test)) to add the constraint, (using mdx (opam :dont-generate)) to force skipping the generation, etc, but I think it will be fairly heavy syntax-wise.

[emillon]

(I'm open to suggestions someone has an idea for a better interface)

[rgrinberg]

Okay, well we can always add such an option later if there's demand.

[Leonidas-from-XIV]

I think backing off if it is already detected in the dependencies is a good approach to allow the user to override it without additional syntax that the user would need to be aware of. I like it.

And yes, it would be great to generate the Menhir dependency with the right lower-bound as I sometimes see packages fail the lower-bound check on opam-repository, having dune generate the depemendency with >= 20180530 will avoid this in the future. Or maybe even >= 20180905 to get the fixes for --explain (though we don't use --strict so it might not even be relevant to Dune).