Add DirectiveNodes, which render to nothing.

The purpose of DirectiveNodes is to turn modes off and on in the
renderer. At the moment, they do nothing, but possible directives would
be things like table cell alignment.
Give toXHTML() the currently enabled directives.

This shared state is updated when DirectiveNodes are rendered.

This is messy, as it involves passing around mutable state. A better way
would be to have a visitor for rendering, which handles this in a
central place. When I get on to adding multiple output formats, that's
the approach I plan to take.
Implement a directive for table cell vertical alignment.

Adds a directive `table-alignment` which assumes (at least, but more
ignored) one argument, which is a valid value for the CSS vertical-align
property. To be more forwards-compatible, it should probably be "top",
"middle", or "bottom".
Add DirectiveNodes to the visitor
Remove RenderedPage and RenderedPageFactory
Refactor to allow for multiple markup renderers.

 - Remove toXHTML from ASTNode, and add in a toSmallString to serve the
   purpose of checking if some rendered AST contains visible elements.

 - Turn MarkupRenderer into an abstract generic class and augment it
   with methods to produce the target type from an AST.

 - Create a CreoleRenderer abstract class, based on CreoleASTBuilder, to
   render markup and track enabled directives.

 - Implement HTML rendering using this.

 - Perform main wiki rendering with the new HTML renderer.
Turn ASTRenderer into a glorified monoid
Remove all reference to HTMl escaping from AST nodes
Remove Renderer instance from Code/InlineCode.

This completes the removal of all HTML-specific things from the AST,
other than Raw, which is needed for the web-based wiki. I don't think
that could reasonably be removed.
Give Languages a nice toString method
Move TABLE_ALIGNMENT_DIRECTIVE to MarkupRenderer, and document it.
Allow rendering of a LinkParts to a URL string in LinkPartsHandler
Implement rendering to Docbook
Correctly handle namespaces in generated Docbook
Implement docbook output with ?ctype-docbook.

This isn't a very good implementation at the moment, as it relies on
passing around the docbook renderer. It's not very scalable. But at
least it works - next on the to-do list is some sort of renderer source.
Implement a registry of renderers.

This is now the soruce of renderers as used in DefaultPageImpl::get().
Renderers are identified by ctype (with a ctype of "default" added for
the plain HTML renderer), and there are two types: stream and page.

 - Stream renderers produce an InputStream which is sent to the client
   through a StreamView with the appropriate content-type.

 - Page renderers produce a String which is inlined into a JspView,
   with the content-type discarded.

 - If there are multiple renderers for the same ctype (why you would do
   that, I don't know), stream renderers are preferred to page
   renderers.
Handle CTYPE_RAW requests through the renderer registry
Abstract out inline renderers from SvnWikiRenderer
Remove an unneeded import
Remove PageRenderers from the RendererRegistry.

Their only use would have been in generating different HTML, which seems
unlikely, so they were dropped.