Fix comment issue bugs.

Changing comment issue states was pretty broken. Some of this was just code that
was never updated when the comments were converted to Backbone. Once I updated
this, I ran into the trouble that existing DiffComment objects were failing to
validate because they didn't have a fileDiffId. This isn't something which is
returned as part of the API responses (for a reason that I haven't figured out
yet), but it's not required when we just want to change the issue state, so I've
changed the validator to only require it if the comment is new.

Testing done: Fixed, dropped, and reopened some issues.
Reviewed at http://reviews.reviewboard.org/r/3998/
Add some helpful comments to BaseResource.ready

Trivial change.

Reviewed at http://reviews.reviewboard.org/r/4005/
Convert RB.Review to Backbone.js

This change converts RB.Review to Backbone.js. This is a little bit more
complicated than one might expect because of the way draft reviews are handled.
The reviews.js code which handles pending reviews always creates review objects
without an ID, which means they think that they're "new". We then fetch a
special /draft/ resource which will redirect to an existing draft. This logic is
encapsulated in a "DraftReview" object. If we try to fetch the existing draft
and it fails, DraftReview will then fall back on the normal BaseResource
implementations and create a new review object on the server when it goes to
save().

Reviewed at http://reviews.reviewboard.org/r/3990/
Some more fixes and tests for RB.Review/RB.DraftReview.

This adds a fix which I had neglected to 'git add' before pushing to rename the
errorText field, and adds some unit tests and fixes to the draft review
functionality.
Remove an extraneous comma in ReviewReplyModel.

This comma would break certain browsers.
Update $.fn.bindProperty to support "text" and "html" properties.

These are not strictly properties in the same way that other things
passed to $.fn.prop() are, but from the caller's point of view,
they aren't much different.

bindProperty can now update the text or HTML of any DOM element
when a model's property changes.
Refactor the screenshotThumbnail code to be largely a Backbone view.

The bulk of $.fn.screenshotThumbail has been pulled out into a Backbone
view. The view handles hooking up events to the model and elements, and
performing modification and deletion actions on the screenshot.

$.fn.screenshotThumbnail itself still exists to query the proper
screenshot to populate the view with, and to hook up events to the
editing state for the review request. In time, this will all move into a
new view that owns review request editing.
Make RB.FileAttachment inherit from BaseResource.

RB.FileAttachment is now ported to Backbone, and is a BaseResource.

Since RB.FileAttachment sends file data one of two ways (through a
new-style file upload, with DnD, or a form upload), BaseResource had to
be modified to handle this, the same way the old RB.FileAttachment had
to.

Now, BaseResources can mark that they have a field representing a file
to upload. If, during save, that field has a suitable file associated,
BaseResource will go down another path for the save operation. It will
structure a payload to put up to the server that contains form data.

(It's worth noting that there's new API out there for making this much
nicer and easier to generate, but it's still a draft and not very
supported.)

If instead we're going through a formDlg (for a manual file upload, not
DnD), then we have to save by doing an HTTP POST for an HTML form, using
our form.ajaxSubmit code. (This is needed for older browsers.)
BaseResource now supports this as well. Basically, if options.form
exists, it will take precedence over all other fields and pass it down
to RB.apiCall, which will do the right thing.

Unit tests were added to this, and other code around file attachments
were changed to properly work with the new class.
Fix a couple issues with resource loading/saving.

BaseResource's URL, when containing an ID, left off the trailing slash.
While it still worked fine, it did result in a redirect, and thus an
extra call to the server for every URL.

Doing a GET had other small but harmless issues. It provided a
contentType and attribute data, even though these weren't wanted in a
GET.