dwconfig.py: allow people to skip supplying an options object for materialize()

If you are trying to run DWiki as a real WSGI application under a WSGI
server, materialize() is the main entry point for creating the ready to
go application object. It turns out that it's convenient to not have to
make up an options object when you do this, so now we allow this.

(Easily running DWiki as a WSGI app requires a writeup and some more
cleanups, but baby steps.)
templates/dwiki/overrides.tmpl: allow for page-type-specific overrides

The short form version of why is that it's useful to be able to override
the normal view rendering for just files, not directories. Before
dwiki/overrides.tmpl changed, this required overriding the full
rendering for the normal view just to get access to the file-based one.
This is kind of silly when we already have a perfectly good set of
mechanisms (used in other places in the templates) for type-based stuff.
pageranges.py: add a new 'cond::pageinblog' renderer

This is a conditional renderer useful purely for checking if this page
is part of a 'blog', ie a section of a DWiki that defaults to rendering
in a blog view.
context.py: add support for per-page context variables

Per-page context variables are automatically cleared when you call
ctx.set_page() to change to a new page. An example of such a variable
is :wikitext:title, the title of the current page (if available and
set yet).
blogdir.py: add a new blog::namedate renderer

It just generates a 'DD Month YYYY' timestamp of the current page.
(Well, with no leading zeroes on the DD bit.)
htmlrends.py: new 'readmore' renderer

This generates a 'read more' link to the page. This is only going to
be particularly useful in blog or blogdir view if you've changed the
default blogentry template.
Significantly reform what wikitext rendering generates (first pass)

NOTE: this involves an incompatible change to the {{CutShort}} macro.
See later.
NOTE 2: this changes what's stored in the on disk render(er) cache.
Much of your old/current renderer cache will no longer be used after
this; you may want to delete it entirely and let things restart from
scratch.

Originally, rendering wikitext into HTML just produced HTML. Over
time it became obvious that this was a design mistake; rendering
wikitext also produces other information (like the title, if any)
and wedging all of these into various special cases was increasingly
awkward. Now I've changed that.

Rendering wikitext now produces a RendResult object that encapsulates
the result of the rendering. This RendResult (and an accompanying
titleInfo dictionary of title information) is what is cached on disk.
Actual template renderers get a RR object and turn it into HTML by
calling an appropriate function. Since the RR object contains a stream
of generated HTML blocks there are now a number of new renderers that
do things like render wikitext without the title or render the full
HTML version of the title, complete with <hN> element.

(Since variations of these renderers are sprouting like rabbits,
specific renderers are highly likely to change in the future. I
think I'm going to have to give in and create renderer arguments.)

In order to cache a single RR object that's useful across multiple
contexts, the implementation of {{CutShort}} had to change. Instead
of aborting the rendering when it triggers, {{CutShort}} now merely
adds a marker in the stream of generated HTML blocks; the full page
is always generated and always stored in the RR object. Turning the
RR object into HTML checks for CutShort markers when appropriate.
This creates two incompatible changes in {{CutShort}}, both of which
I think no one will notice:

* {{CutShort}} is now only valid at the beginning of a non-indented,
  non-nested line. This matches how I've always used it, but means
  that you can no longer cut a paragraph in the middle or the like.
  This is due to technical limitations of the implementation and may
  change.

* since the entire page is now always generated, access restrictions
  that were below a {{CutShort}} will now always trigger. It used to
  be that you could have a non-blocked teaser, a {{CutShort}}, and
  then an access restriction that would block full-page rendering.
  Not any more. Again, this was an obscure and undocumented feature
  (and probably not a good idea anyways).

This change removes wikirend.registerCached(), which required a change
to atomgen.py to stop using it. I've also added a new renderer,
atom::pageterse:notitle; this uses the new wikitext rendering stuff to
skip the title of a page when turning it into an Atom feed entry.
Template updates to take advantage of the new rendering

The big change is that 'blog entries' now show the entry date below the
title (if the entry has a title; if not the date is shown just above the
entry text). This makes entry dates more visible, which is something
that I've come to believe is important in a blog. Doing this requires
a CSS update, so there is a new version of test/statics/dwiki.css.

It also switches Atom feed generation to generating entry HTML that does
not include the title. Atom feed entries already include the title as an
Atom <title> entity, so this stops them from stuttering.