stub out an endpoint which dumps SQL tables

Checkpointing this because it runs and is fun for debugging,
but I am about to split it into two classes and do getChild() hacks
Working table dumping endpoint(s);

Run scratch/sql/db.sh and go to http://localhost:8080/tables/analysisresults to try it out.
Tidy the last commit.
dataset (and, thus, SQLAlchemy) is now a dependency.
Give HTTP 503 if at request-time, the db is unavailable.

This is instead of connecting at init and failing totally if the db is down then.
The method I used is sketchy (I looked into dataset's source code and learned how
to tweak their privates), because dataset seems never to have been tried on a long-running
server; it only has connection pooling and reconnects as an accident of being written on SQLAlchemy:
there is no public API that does "reconnect and sync schemas" inside of dataset.
I reported the issue at https://github.com/pudo/dataset/issues/88 which took longer
 than writing the code, of course.

Also, factor the in-memory csv dumping code.
Corner case: return 503 if the database breaks between finding the table and reading it.

We should figure out a good way to wrap all our database handlers so that they
*all* catch OperationalError and return 503 the same way.
remove the now-unnecessary specialcasing

So now, the URL structure is always the same
and a downed database is handled fluidly at request time
instead of fragily at init time.
Tidy up the csv dumper.

It's now dataset.freezes() (same naming scheme as {json,pickle}.dump(s)?)
and API-compatible with dataset.freeze().
Test case for a bug in dataset
Missed this .gitignore! Very important!
stub out THANKS.md
In lieu of coming up with better names, document what I did today and hope someone comes along and sees this note.