Bug Fixes and convergence testing

@adamhooper This PR addresses the bugs you caught last time (e.g. it uses a better font stack, clearer names, etc). Re the most substantive issue—how to stream from the server—it sends a blob of data every time the server processes 100 documents. This is roughly analogous to having the server send new data every x milliseconds. But doing it after a certain number of documents, rather than after a certain number of milliseconds, was more convenient: first, because timers are a pain, but also because it simplified my implementation of convergence testing (by simplifying the logic for predicting when the doc set will converge).

Re the convergence testing: obviously, this isn't statistically valid until the docs are coming back in a random order. But I figured I'd get the code ready anyway. On the Pitchfork doc set @jstray gave me, the wordcloud converged (meaning that the cosine similarity between wordcloud n and wordcloud n+1 was > .9999) after only 2,800 docs. (It's a 13,200 document set.) As a result, the server was able to return the "final" data in ~6 seconds, as opposed to ~17 seconds before. So we got a 3x speedup, even though we're only processing 1/5 as many docs. We didn't get a bigger bump because we're processing the token data (i.e. finding the top tokens and, now, computing computing the cosine similarity) more often; now we're doing it once per 100 docs until convergence, whereas before we were only doing it the 5 times we were responding. It'll be interesting to see how we can set `incrementSize` to minimize total response time (i.e. balance fewer times processing the tokens against converging after reading fewer docs).
This incrementSize assumes a specific bandwidth between plugin and server (on the order of ~100 docs/sec).

That assumption can break in two directions:

* A big docset full of tweets might stream at 5,000 docs/sec. You'll send 50 jsons to the client when one would do. The client will try and re-render 25 times per second, which will freeze the UI.
* A small docset full of 100-page PDFs might stream at 2 docs/sec. You'll process the entire docset before even calculating progress.
* A plugin residing far (in network terms) from the server might stream at 10 docs/sec. You'll only calculate progress once every 10s.

You are using a magic number, "100", to estimate time. There is a better way to estimate time: Date.now(). It's practically instantaneous, and we don't even need to ponder proofs about why it should work or test that it works in practice or anything.