We had a few bugs that were causing things to get weird when a review

request was discarded before its initial publish, and then attempted to

use again.
The first bug here is that doing an rbt post -r against the discarded

review request would create the draft, but leave the review request in

its discarded state. I've changed the POST

/api/review_requests/<N>/draft/ API to reopen the review request in this

case.
Second, because there's some history present, the subsequent publishing

of the discarded-then-updated review request is creating change

descriptions. For the most part this is fine, but the commit list field

wasn't correctly handling the case where the change was adding the first

diff in the history. This affected both the serialization to the

ChangeDescription as well as the rendering methods.
Last, the draft banner was unconditionally trying to add an interdiff

link. I've changed this to work like other parts of the codebase where

we check the diff revision first.

Ran unit tests.
Manual testing:

Created a new review request draft, then discarded it. Saw that

   the old draft diff was discarded as expected.
Ran rbt post -r to update the previously discarded review

   request. Saw that it was reopened, and that the diff was

   correctly attached to the draft. Checked that the draft banner

   did not attempt to give us a bogus interdiff link.
Published the draft. Saw that publishing worked without showing

   errors, and that the change description was rendered correctly.