Add support for dependent pages

Instead of returning a string of html, you return a map:

 {:contents "the html",
  :dependent-pages {"/uri" "contents"}}

These dependent pages are then also served and exported.

This allows you to keep your page-creation logic sane while
creating subpages for them, especially when using lazy evaluation of
pages with the get-page feature.
> Everytime a page is served, the pages map (atom) may be updated. So serving an already generated dependent page is not a special case. It's just a page.

This won't work. There is no pages map atom. We re-fetch all pages with `get-pages` for every request.

> If we're going forward with dependent pages as a special case.

I'd be interested to hear an alternative!

> I wonder if we could make the logic easier to follow if the following is apparent in serve-pages [1, 2, 3...]

Right now we have 1) serve a page, 2) try serving a dependent page. You want to tease apart the check for the existance of a dependent page, and the serving of it, so the not-found can be placed back into `serve-pages`? I have a feeling that would be painful with the last ditch effort fallback.

> Here's something that surprised me: dependent pages are not resolved when the host page is rendered. Instead, they are attempted resolved when we're heading for a 404.

The dependent page might have changed since you last looked at the host page.