TODO on word_view animation
stabilize explicit sorts in index.js
utils.stable_sort

TODO: test this. Sure to be slow, but shrug.
stabilize topic_docs sorting
stabilize doc_topics
stabilize sort in topic_words
stabilize word_topics
stabilize year_topics

not currently called from index
remove unused generic stable_sort method
note on speed prob.
display an alert when files are missing

missing info.json generates only a warning

error, warning, and loading alerts are all bootstrap alerts now.
refactor m.dt condition in model_view
refactor view_(warning|error) into _alert
TODO note on topic_docs
experimental: topic_docs moved into a Worker

which requires some refactoring. the dt object methods get moved off into a
separate file. For this first pass, I have left duplicate copies of the
doc-topics matrix, one in the model (main thread) and one for the
worker, so I wouldn't have to make every single dt access call out to
the worker. But m.topic_docs() now takes a callback that receives
the result of the calculation. This is used in topic_view_docs() to
render the table of top docs for the topic asynchronously.

The worker in js/model_worker.js responds to messages sent by the model
object in the main thread. So far it only knows "topic_docs," but
eventually it should hold all the model data and handle all the lengthy
computations. The model stores a d3.map of callbacks on its interface to
the worker (this is needed so parallel requests don't cross).

It's not possible to use the d3 array utility routines in the worker,
because there is no "document" object in the worker's thread and d3
requires one. So I've copied those routines into utils, which can be
in the worker's thread.

The topic_view should give a visual indication that a calculation is in
progress. index.js has a view_calculating function but it doesn't do
anything yet.
calculating messaging for topic_docs
progress in refactoring: view.topic

Putting the model in another thread makes it necessary to work out more
carefully what data the views actually need. This leads pretty naturally
to an MVC-style architecture, so I'm going to go ahead and separate out
the view code completely. There is now a view object which accepts
messages from index.js to draw views. So far the only messages it knows
about are the parts of the topic view (view.topic, view.topic.words,
etc.).

Also moved doc_topics off into the worker, with the requisite
modifications to the doc_view (but not yet factoring that out
completely).

Also: topic_words now returns a list of objects rather than just a list
of words that have to be passed back to the model, in preparation for
further refactoring.

In this intermediate stage, there are two copies of the document topic
matrix: one is held in the Worker thread, and one is still held in the
main thread.

Finally, this gave me an opportunity to reconsider the render_updown
architecture and buttons, which produce more visual interference than
they're worth. They are partly but not entirely removed in this commit:

- topic_view: words and docs use the settings held in the VIS object
- doc_view: just show all the doc_topics.
view_loading etc. -> view.loading etc.
view.doc encapsulated

This uses the threaded doc_topics call as well, though in practice this
is pretty fast for 100ish topics.
fix missing grid view words

errant parenthesis meant all words were getting size 0.