This stashes the HTML version of every entry in memory and uses
Mojo::DOM to extract headers from the markup for use as titles.
Titles are displayed in $self->{page_navigation}, now available
inside templates as ${page_navigation}.

In order to keep Mojo::DOM from choking on other input, it uses the open
pragma to open everything as UTF-8 by default, which also eliminates a
whole class of character encoding bugs and removes some fiddling with
Encode::decode() from feed_print().

This is all obviously a more memory-intensive, but caching the markup
turns out to have the side effect of making it much faster to render
even a large site, probably as much as anything because the HTML in
question is only getting generated once per entry instead of
(potentially) 2-3 times.

This commit isn't very atomic.  In the process of roughing it out and
testing it, I made a small pile of minor but potentially breaking
changes:

  - Removed entry_map from settings and hardcoded handling of various
    types of entry as some if-statements instead.

  - Removed embedded_perl flag in settings - was always turned on in
    practice, and wasn't very coherent since templating would have
    broken without it.

  - bin/wrt-display - now handles the "feed" alias correctly

  - EntryStore: now supports retrieving values for properties with
    prop_value() - this isn't currently used, but it seems like a
    reasonable extension of the property idea.

  - Added `wrt ls --with-titles`.

  - Added dependency versions to Build.PL.

  - Refactored Markup's line_parse() a little.

  - Refactored some tests to give cleaner / more useful output.

  - Renamed default template file to "default".

- adds include_process() in WRT::Markup
- moves eval_perl() into WRT::Markup.  The way object instances are
  composed (and instance methods called) here still feels pretty janky,
  and this does nothing to help the situation.
- changes all existing $root_dir instances to $entry_dir; adds a $root_dir
  which represents the root of the archive (top-level folder containing
  the wrt.json file)

I'd be worried about the $root_dir change if I thought this module had a
single other user in the wild, but I strongly doubt that it does.  If I
am wrong and you are that user, I apologize sincerely in advance.

The include feature still has fairly unsettled semantics, but it gets the
whole thing much closer to a usable site generator.