Offer helpful RBTools setup instructions in the repository list.

This updates the repository list to have helpful action links for
getting RBTools configured against that repository. When the admin
clicks "RBTools Setup", it will pop up a modal dialog box showing the
setup instructions for that given repository.

To make room for the new column, I've also shortened the label for the
"Show this repository" column in the repository list. Upcoming changes
will add new actions to this list.

Reviewed at https://reviews.reviewboard.org/r/6306/
Only show the drag and drop indicator when the review request is editable.

If a user wasn't logged in, or they didn't own a review request, they would
still see some visual feedback when dragging files over their browser window
inviting them to upload the file. This change fixes that.

Testing Done:
Ran JS tests.

Tried to drag-and-drop a file:
  as the creator of the review request - indicator appears
  while signed in as an admin - indicator appears
  while signed in as a different user (not admin) - indicator does not appear
  while not signed in - indicator does not appear

Bugs closed: 3542

Reviewed at https://reviews.reviewboard.org/r/6312/
Reject PUT with a changenum on file-only review requests.

When updating a file-only review request (which doesn't have a repository), it
was possible to pass in a changenum field, which would then cause a 500 error
trying to fetch the scmtool. This change makes it so that we return
INVALID_CHANGE_NUMBER if there's no repository (since they're all invalid).

Testing done:
- Ran unit tests.
- Used cURL to reproduce the original bug and saw that I got an error message
  instead of a 500.

Reviewed at https://reviews.reviewboard.org/r/6311/
Add a field on Repository for storing a UUID for incoming webhooks.

This adds new Repository.hooks_uuid, which is used for matching and
validating incoming webhooks. How this is used is up to the hook
implementation, and can be part of the URL, part of HMAC validation,
or whatever else makes sense.

This field is not exposed in the API. It will instead be used by the
various HostingServices in whichever way makes the most sense for their
implementation, and exposed to the user through an upcoming change that
will allow them to provide hook instructions.

Reviewed at https://reviews.reviewboard.org/r/6310/
Add better validation of incoming webhooks for GitHub.

Incoming GitHub webhook requests for the close-submitted webhooks are
now safe from unintentional requests (for incompatible events) or
malicious payloads (from people guessing the URL and sending payloads to
close various review requests).

We now require that the webhook on GitHub be configured with the Secret
field filled out. It must be set to the value of the repository's
hooks_uuid field. The incoming payload will then be validated for a
signature generated with those payload contents and that secret.

The handler will also filter out non-push events, in case the webhook
was configured to "send everything."

This change (and the upcoming ones for Bitbucket and Google Code) do
break backwards-compatibility for existing hooks, but this is necessary
(and we have labeled this an experimental feature).

An upcoming change will assist users in filling out the webhook field
information, along with the value for the Secret field.

Reviewed at https://reviews.reviewboard.org/r/6313/