Provide a way to call dune programatically

Hey dune team,

I'm opening this issue to showcase a feature request that I came up on my usage of dune, but recently a user of one of my libraries made a clear good use-case and I didn't find any discussion online about it.

I would like to use dune as a library and call dune build/exec in my own executable/library which later can be released as a package. Why?

Allowing as a library will make authors provide better experiences for their users and could potentially do all sort of things.

Wrapping a cli

Dream could create a dream-cli which runs the eml rules on all eml files by default, or configure a folder templates where all files are compiled with dream-eml.

To give a little more context, while using Dream you need to add those rules into your dune file with certain degree of friction: https://aantron.github.io/dream/#templates, similarly happens with atd where .atd files need to be generated by an external program.

Allow any random use-case

Another possible benefit is to allow nasty hacks made by people who don't know the system well. This sounds a very bad idea but will enable more advanced users to workaround dune. This bypass of the manual rules or other methods, can release some pressure on dune development.

For example (for giving an example that I used) instead of having a menhir integration in dune you could tell menhir authors to say "no" to an integration and just use the dune programatically approach. (I'm not proposing to remove the menhir integration, but rather a future use-case)

Probably with manual rule creation most of this "features" are already available, but I have found that it's an intimidating part of the dune interface and often desired to be less boilerplat-y.

(cc @joprice)

Previous art

• esbuild https://esbuild.github.io/api/#overview (and remix.run as a wrapper)
• webpack https://webpack.js.org/ (and https://nextjs.org/docs as a wrapper)

Start by reviewing Dune's existing command-line and build-system interfaces; the issue does not name specific files, tests, or entry points. Compare the proposed library use with the esbuild and webpack APIs linked in the issue. Done means a concrete, maintainable programmatic interface is defined and its intended use cases and boundaries are documented.