Use "six" to abstract dictionary iteration and callable for python 2/3

I'm starting to work on porting our codebase to be compatible with both python
2 and 3. In python 3, items(), keys(), and values() are all iterators by
default and the old iter*() methods are gone. The "six" library includes
abstractions to handle these.

In addition, for some strange reason 'callable' is gone in python 3.0 and 3.1.
They brought it back in 3.2 (which may be a reasonable minimum), but for now,
to get the 2to3 tool to shut up, I'm using six's abstraction for that as well.

Testing done: Ran unit tests
Reviewed at https://reviews.reviewboard.org/r/4895/
Move review request draft banner logic into new classes.

This moves all the logic for dealing with draft banners into a set of
new classes in ReviewRequestEditorView. These will allow
ReviewRequestEditorView to dynamically create these banners, instead of
requiring a page reload.

Right now, a page reload is still used, so as not to make this change
any larger than it already is. Dynamic updating will come in a future
change.
Fix discarding replies.

Discarding replies ended up in a loop that would terminate when the
delete path tried to access state that was previously removed. This
happened because we were resetting the ReviewReplyEditor's state when
the ReviewReply's 'destroy' signal was emitted, but we really wanted to
listen to 'destroyed'. Listening to this fixes the loop and reply
deletion.
Move the static media bundle definitions out of settings.py.

The PIPELINE_CSS and PIPELINE_JS definitions were growing pretty large,
so I've moved them out of settings.py and into their own file. They're
imported directly into settings.py, so nothing changes there.
Fix editing close descriptions when a review request is closed.

The ReviewRequestEditor's editable field was recently changed to factor
in whether a user has permissions to edit the review request, and
whether the review request was open. This broke editing close
descriptions for closed review requests, since that depended on the
editable property as well.

Internally, Review Board has separate permissions for the abilities to
close review requests (and alter their close descriptions), and edit
review requests. That's now replicated in the JavaScript.

Instead of passing editable to the ReviewRequestEditor when
initializing, it passes mutableByUser and statusMutableByUser, and it
then calculates editable and statusEditable. The field editors can
respect either of these fields, depending on which field it is.