Dispatches filters listed in an entry's filters.prop to scripts under
$wrt->{filter_dir}.

This is inefficient, in that it starts an entire process (at least) per
filtered entry.  On the other hand, it's a pretty clean abstraction, and
it means that filters could be implemented in whatever language.

Adds filters/ creation to wrt init.

You can add a filters.prop in an entry, containing a list of filters to
apply which will be pulled out of the guts of wrt.  I'm not sure if this
is a good idea or not, to be honest.  It's elegant enough, but it feels
a bit obscure.

I'm also not sure if it should accommodate the user writing custom filters
that can sit in the wrt repo, but it kind of feels like that would be
more in the spirit of things...

- adds an example "flat" site with, for now, a single index in root for
    testing purposes
  - wrt-render-all handles default entry instead of just using "new"
  - EntryStore::all_renderable() correctly filters out paths ending in
    "/index" instead of "index", which if nothing else corrects a subtle
    bug that would have gotten in the way of naming something "windex"
  - WRT::handle() will return the contents of a root-level "index"