Add user comments

After this is merged, you'll need to run:

```
CREATE TABLE user_comments (
    id BIGSERIAL PRIMARY KEY,
    vcf_id BIGINT REFERENCES vcfs ON DELETE CASCADE NOT NULL,
    sample_name TEXT,
    contig TEXT,
    position INTEGER,
    reference TEXT,
    alternates TEXT,
    comment_text TEXT NOT NULL
);
```

On the backend, the PR adds the user comments table and an API for accessing comments in `comments.py`.

On the frontend, I changed `RecordStore.js` to recognize the difference between a selected record (showing the comment box) and Dalliance being open (which is now accessed from the comment box area). I introduced `VCFRecordComment`, which displays comments in a textarea. A new column is also added to show whether a row has a comment.

A few notes:

- I wanted to start with plaintext comments, and save author/tagging/other fanciness for later.
- Right now, we just retrieve all comments for the VCF, rather than the comments for the rows shown. The latter seemed like it'd be a premature optimization, since I don't imagine that many user comments.
- I wanted to use Bootstrap's buttons and form control, so I pulled those specific pieces out to use on Examine.
- Overwritten comments are currently a problem. User A might accidentally clobber User B's comment if he hasn't loaded User B's comment.
- Similarly, multiple comments with the same contig/pos/ref/alt/sample name can happen. (Due to out-of-sync clients.) Currently, in that case, one of them is chosen to display. We shouldn't allow that situation to happen. (SQL constraints, displaying errors to the user, etc.)
- I think a good way to display all comments on a page will be to integrate with CQL to filter by rows with comments, but that's not a part of this PR.
- The comment icon can be improved. Maybe a glyphicon would work?
- Scrolling the row to top mostly still works, though it doesn't always go all the way to the top.
- I should add some tests.

![screen shot 2014-12-08 at 12 30 52 pm](https://cloud.githubusercontent.com/assets/322932/5345384/68157b9e-7ee5-11e4-9333-cdee885ea7fd.png)

(I'll update `dpxdt` after the review, before merging.)
Got it. So we're "hard-coding" the number of columns via the `columns` object, so I'd just keep using that in lieu of adding a new convention. The `columns` can be modified at runtime, of course, so it's not really hard-coding, per se. It's safe to assume that any row within the table will have the same number of columns as the header of the table.