Make linkifyReviewRequests and linkifyBugs produce markdown output.

This change adds a 'markdown' parameter to the review requests and bugs linkify
functions that enables them to produce output in markdown format (as opposed to
HTML).

While I was doing this, I noticed that writing "issue #2, issue #4" would
include the comma in the first bug number link. I've fixed the regex to handle
this case properly (commas are pretty unlikely to be part of a bug number), and
added a relevant test.

Testing done:
- Used this in conjuction with the markdown changes.
- Ran js-tests.

Reviewed at https://reviews.reviewboard.org/r/4491/
Make some CSS selectors more specific to avoid style bleed into descendents.

The list of replies to a comment on the review request page are arranged
semantically, using ul>li. Unfortunately, the reply-comments style bled through
to *all* li descendants of the top-level list, and not just immediate children.
This meant that when markdown formatting used a list (for actual lists, or the
way that it formats code samples), it would have all the junk used to display
the replies.

Similarly, a couple of the elements inside the change description banners at
the top of the page had loose selectors which caused styles to bleed into the
<pre> unnecessarily.

Testing done:
Saw that lists inside the .reviewtext and change description elements didn't
inherit a bunch of junky styles.

Reviewed at https://reviews.reviewboard.org/r/4492/
Fix the field name for changedescription in drafts.

The DraftReviewRequest model was trying to pull out "change_description" from
the JSON payload for the draft's change description, but the API field name is
'changedescription'. We didn't notice this because it wasn't actually used
anywhere (the change description was saved but never re-read).

Testing done:
- Ran js-tests
- Used this in conjunction with a change that adds a formatter to the
  changedescription field in the review request editor, causing the new value
  to be read when we save the draft.

Reviewed at https://reviews.reviewboard.org/r/4496/
Don't set an index on FileAttachment.repo_path.

MySQL has a rather low-ish limit for indexes on Unicode tables. We hit
that with the index for the new repo_path field.

This fixes the model and the initial evolution to not set an index. A
new evolution was added to fix the databases synced since the original
change, so that our state matches up, and otherwise will do nothing to
an existing database.
Add support for showing diffs of file attachments in the diff viewer.

Review UIs can now opt in to providing diffing functionality for file
attachments. A ReviewUI subclass that has supports_diffing=True will
have the whole width of the diff table to render in. It will be given
both the new file's fileAttachmentID, and the original's (as
diffAgainstFileAttachmentID).

FileAttachmentComment can now specify a FileAttachment that's being
diffed against. The ID for this can be set when creating a new comment
in the webapi.

FileAttachmentReviewUI will properly filter the comments when passing
down to the JavaScript to ensure only the comments matching that diff
range (or, if not using a diff, comments that are on a single
FileAttachment) are passed down.

It's up to the review UI to decide how to render the diff.
Remove the evolution to delete FileAttachment.repo_path's index.

Turns out this evolution doesn't work everywhere, so delete it.

Anyone who updated their database when repo_path was added will likely
need to run evolve --hint --execute. This will only affect developers
who updated in the past several days.
Revert "Remove the evolution to delete FileAttachment.repo_path's index."

This reverts commit a7c85620c570e0f344fdac098052f6bda424fc6e.

The problem I encountered was due to my database, specifically.
Simulated upgrades don't show the same symptoms.
Don't auto-open the change description editor when loading a draft.

One thing that's always annoyed me about loading a public review request with a
draft is that the change description editor box auto-opens. Until now this has
been a mere annoyance, but with the markdown change, it's downright ugly. This
change kills that behavior.

Testing done:
Loaded a review request with a draft and saw the change description stay where
it was when the page loaded.

Reviewed at https://reviews.reviewboard.org/r/4497/
Fix expanding the top-most chunk of a file.

The logic for handling chunk expansion was doing a truthiness check on
chunk_index, instead of comparing it to None, preventing chunk 0 from
expanding properly. We now compare to None, like in all other cases.

Fixes bug #3026.
Merge branch 'release-1.7.x'