Documenting Dune's internals

There are many things that Dune do that are complex or at least not immediately obvious. For a software such as Dune that we intend to maintain for a long time, I think it is important to document such implementation designs. This will be helpful to have a clear mental model of how Dune works. It should benefit not only Dune developers and contributors, but also users as well, as understanding how Dune works can help debugging problems. We should however make it clear what we consider as implementation details that might change in the future, so that users are aware of it.

@snowleopard started the trend with documenting the shared cache, and I think we should follow with various other parts such as:

• how we compile libraries using module aliases
• how we handle ppx rewriters
• the interactions between dune-configurator or dune-build-info and Dune
• the computation model of Dune
• Dune's structural concurrency monad
• the path Dune follows to determine how to build a target
• and probably other things

Writing such documentation takes time and shouldn't be our highest priority, but we should still allocate some time to do it.

The issue names no files, tests, or entry points; begin by reviewing the existing shared-cache documentation and choosing one focused area such as module aliases, ppx rewriters, dune-configurator, the computation model, structural concurrency, or target-building paths. Done means adding maintainable documentation that explains the implementation design and clearly identifies details that may change.