NOTE: This commit requires updating your special Dune to the
[lukemaurer:special-dune-2.9][] branch.

[lukemaurer:special-dune-2.9]: http://github.com/lukemaurer/dune/tree/special-dune-2.9

The current system relies on modifying the `ocaml/` subtree in place.
This is fragile, and is particularly a problem now that we have stage1
and stage2 as build contexts sharing a `_build` directory (and hence
sharing saved build state): stage1 and stage2 can clobber each other's
inputs, triggering unnecessary rebuilds.

We can avoid ever modifying a file in `ocaml/` by exploiting two
non-obvious properties of Autoconf:

- a `configure` script can be run from any directory and will only
  create files where it's run

- the `config.status` script that `configure` generates can generate
  individual files on demand, also from any directory

For stage1 and stage2, then, we can just use `configure` to generate
a `config.status`, and then Dune can take care of running
`config.status` for itself - which naturally happens in the stage's
own `_build` subdirectory. There's some faff required to use a
`config.status` as a Dune action, since it normally creates files in
subdirectories, which Dune doesn't support. Also, Dune wants to know
exactly what files `config.status` will create, so we end up tied more
closely to the upstream `configure.ac` than we might like. Finally, we
have several Dune actions that run Make and thus depend on
`Makefile.config`, which has to be declared explicitly now because
`Makefile.config` is not in the source tree. But in return, the build
should be considerably more robust, and we continue moving work from
Make to Dune (`make stage1` and `make stage2` barely do anything more
than call Dune).

Also added a comment to make the new stage0 config code a little
clearer.