More Parsoid output compression benchmarking: test impact of chunk size.

Compressing each article individually leads to a greater overall size
than chunking multiple articles together -- but how large is this
effect?  What should chunk sizes be -- too large and we have to
decompress a lot of irrelevant data in order to get our article;
too small and compression ratios suffer.  The test-parsoid-sep.js
script attempts to obtain data to answer these questions.
Add results for lzjb compression.

lzjb is really fast, but it uses a 1k window and so doesn't benefit much
from chunking.
More compression datapoints.
Add experimental HTML preprocessor for better compression.

The idea was to separate out the HTML, text content, and attribute
contexts so that similar content was kept together.   This helps lzjb
compression, but doesn't seem to help anything else -- presumably we're
breaking up some long runs of similar content by splitting this up
this way?
Update compression-testing tools with lzjb.
Add language to page path; draft new settings page
Update configuration to point to public WMF Parsoid service.

The _wikitext endpoint is not public, though, so we still need to use
our private appfog server for our local pages.  Probably should be
changed by preprocessing our wikitext sources through wmflabs
_wikitext endpoint and storing the DOM sources.
Update volo tool.
Refactor page/db split.
Update TODO list.
Update the 'about' page text.