Documentation generation produces consumable output in one command

Building the docs target now generates the reference and leaves finished
documents in the build tree's docs directory: pdf/ holds the compiled
PDF, html/ holds the browsable reference when that format is enabled.
Doxygen and LaTeX work under docs/tmp/, which clean removes along with
the rest of the tree.

The reference has a front page and a structure. The markdown documents
in docs/ are part of the input, OVERVIEW.md becomes the landing page,
and the rest follow as chapters ahead of the namespace, class, and file
reference. The module contract, previously a plain comment block
invisible to Doxygen, is a page in its own right.

Struct and enum members throughout the headers carry documentation, on
their own lines above what they describe.

docs/CONSUMERS.md

@@ -34,14 +34,16 @@ To point a context elsewhere, pass overrides — every field is optional:
 
 ```
 dpm_open_overrides ov = {
-    "/path/to/conf.d",    /* config_dir:  NULL = /etc/dpm/conf.d/      */
-    "/path/to/modules",   /* module_path: NULL = config, then default  */
-    "/path/to/root",      /* root: target root for package operations  */
-    -1                    /* log_level: -1 = from config               */
+    "/path/to/conf.d",
+    "/path/to/modules",
+    "/path/to/root",
+    -1
 };
 dpm_ctx* ctx = dpm_open(&ov);
 ```
 
+Leaving `config_dir` NULL selects `/etc/dpm/conf.d/`; leaving `module_path` NULL selects the configured value and then the built-in default; leaving `root` NULL selects `/`; a `log_level` of -1 takes the configured value.
+
 The root override is what makes chroot builds, image assembly, and sysroot management work: package operations act on the given tree instead of the running system. Multiple simultaneous contexts with different roots are legal.
 
 ## Acquiring and using modules
@@ -58,9 +60,11 @@ libdpm-core.so validates the module completely at load; a handle is returned onl
 
 ```
 dpm_module_info info;
-dpm_module_info_of(ctx, mod, &info);   /* info.name, .version, .description */
+dpm_module_info_of(ctx, mod, &info);
 ```
 
+`info` carries `name`, `version`, and `description`.
+
 Deciding whether that version is suitable is yours. libdpm-core.so applies no version criterion of its own — a handle means the module is valid, not that it suits you.
 
 **`dpm_execute`** invokes the module — a command name and arguments:
@@ -77,7 +81,7 @@ This is the only path into module code, and it is the same path the `dpm` binary
 dpm_cursor* cur = dpm_list_modules(ctx);
 dpm_module_info info;
 while (dpm_cursor_next(cur, &info) == 0) {
-    /* info.name, info.version, info.description */
+    /* each iteration fills info */
 }
 dpm_cursor_free(cur);
 ```