The Review Request banners (close banners and draft banners) were a weird mix

of backend- and frontend-driven code. When rendering the review request page,

we'd render the banner from a Django template and then "import" it from the

javascript view. We'd also have some actions (such as changing a field or

marking the review request as closed) that would create a new banner entirely

from javascript. These two code paths used slightly different markup, and made

it annoying to think about and to test.
This change updates things so that all of our banners are created entirely in

javascript. This involved quite a few changes:

The showBanner implementation would unconditionally end up showing a draft

  banner if the review request wasn't closed, because it had previously only

  been called when doing something that would create a draft. We had an unused

hasDraft field on the ReviewRequestEditor, which I've repurposed for use

  here in determining whether we should show a banner or not.
Updated the js-tests to account for the fact that we now need a draft present

  in order for the draft banner to be created.
Because the initial text for the close description or draft change

  description were rendered from django, we didn't have the rendered text

  available in javascript. I've plumbed this through the ReviewRequestEditor.
I ported over the "Send E-Mail" check-box and "This draft adds a new diff"

  info box into the javascript-driven draft banner.
Tweaked the spacing a little bit in the draft banner with the "new diff"

  link.

Verified that opening up existing review requests with drafts, or closed

  review requests (both submitted and discarded) would create the correct

  banner, and that the change description/close description text was correctly

  presented in both markdown and plain mode.
Verified that banners were created when making changes to fields or closing

  the review request.
Ran unit tests.
Ran js-tests.