Fixed bad geometry relay.

Of course this HAS to happen after I published 1.0.8.
Skipped features that will be deleted anyway.

This is actually highly important because otherwhise doc.GeoJSON moves into a
deleted document and becomes unreachable.
Corrected some bad grammar.
Changed filtered replication to include all attached docs.

Even though the previous selection replicated a self-contained database, there
is no way to prevent someone from changing references and then replicating back
to master.
For the sake of just keeping my database sane, I included every document that
is attached to any used geometry.
Moved DOM query "#table th" outside of the loop.
Reviewed comment that clearly must have been from the early days.
Added special filter 'redo:filter'.

It stops inspecting filters at the specified one.
Added document tag 'skip_me' to skip documents (once).
This makes use of _view/types-year, supposedly.

Granted it needs a little tweaking in the folloging way: I re-stacked the last
filter and tell filter_documents to run it by _list/tabulate again. This is
because I end up with wrong document times otherwise. Pre-filtering mere types,
however, works precise and doesn't require any post-filtering.
On the bright side, I experienced improvements in response time already, so
this seems like the way to go.
Deleted skip_me tag unconditionally.

The other version looked stupid.
This avoids reprocessing the prefilter if only types are involved.

I've tested it and I need to test it even more because right now I am
absolutely not sure if this works the right way.
Simplified truncation in _view/bbox.
Reduced amount of pre-filter keys for the 2nd reduction.

At the 2nd reduction neither time nor types are carried into options
necessarily, so the pre-filter has to look the missing one up in the filter
chain.
Now, because I've allowed to branch into pre-filtering only for the 1st and 2nd
filter, the actual look-up-process just has to go through filters[0] and [1]
and this is why it looks as simple as that. My assumption has always been that the
amount of documents must have reduced sufficiently after that.
Improved _view/types-year to use 'sensible granularity'.

Previous tests showed that still way too many documents have to run by the
post-filter because using no range as key if doc.time spans over more than one
year just isn't restrictive enough.
So I've come up with a smarter scheme that is still kind of intuitive:
- Extract the very beginning and the very end from doc.time,
- strip everything except for the year,
- emit range if its a single year or a one-sided range, or
- round to the next five years if doc.time spans over five years or less, and
  ditto for ten, fifty and a hundred years. For instance, "1960-1992" spans
  over 32 years, so a simplified range is "1950-2000".
At the current data set, I end up with 48 unique keys of 3174 in total, and
awesome performance, so job well done I guess.
Turns out I can't do anything (fixed a937bd03f).

The worst part is that this is now a revert of a revert.
Fixed uncaught exception thrown in filter_documents.

This happens when spatial filters clean up the filter queue by using {union:[]}
as the first argument. This causes all filters to be collapsed and the
collapsed filter runs by _list/tabulate. If it contains either time or type,
pre-filtering is used (as it still should), but it stacks {redo:filter} on top
of the argument list. filter_documents then gets confused because it processes
{spatial:relation} before {redo:filter}.
Fixed pre-filter ignoring stored document sets.

These documents have a keep_me tag but the pre-filter ignored it when no redo
was needed.
Renamed _view/types-year to type-year.

It is because each doc emits just one type so this improves semantically I'd
say.
Used $.text where $.html wasn't really needed.

There a last one that I haven't yet resolved.
Removed parameter 'rereduce' where it was unused.