Add the requested hostname to the Perforce repo path lookup.

When attempting to find aliases for the requested hostname for a
Perforce server, we were assuming that gethostbyaddr would return the
original hostname as the first result. This isn't always the case,
though. We now factor in the original hostname in this list.

We also now simplify repository lookups in the case where there are no
aliases by returning the repository path directly instead of a list of
repository paths. That prevents having to fetch the whole list of
suitable repositories server-side and scanning through them for matches.
Release RBTools 0.5.3.
Merge branch 'release-0.5.x'
Fixed a typo in the release notes.
Merge branch 'release-0.5.x'
Fix the release script's destination directory.

The release script was placing things in product directories off the
root, instead of in /releases/. This was a copy-paste issue from an
older broken script in Djblets.
Merge branch 'release-0.5.x'
Implement posting for shelved perforce changes.

The perforce shelf is kind of like a shared "git stash". When you shelve a
change, it copies the data from your working directory over to the server. What
I didn't expect is that it also leaves your working directory the same, with
the same open files (which can then be reverted).

We can get the file list for a shelved change via `p4 files //...@=CLN`, and
the file contents via `p4 print //path/to/file@=CLN`. This lets us use a very
similar implementation to pending changes, with the exception that the "new"
files are fetched from the repository instead of just using the working copy.

The perforce documentation is full of lies. Among other fantastical claims, it
asserts that shelved changes have a 'Status' field of 'shelved', when in
practice, they're still 'pending'. I've made changes to parse_revision_spec to
treat shelved changes the same as pending ones, and then made some changes to
the pending diff code path to look on the shelf if there are no open files in
the changeset.

The one major limitation that I wasn't able to work around is that when you
shelve a change containing file moves, there doesn't seem to be any way to know
which "move/add" corresponds to which "move/delete". The usual ways of doing
this (looking for "movedFile" in fstat, or looking in the filelog) don't work
for shelved changesets. I suspect that this is just an oversight that will be
corrected in the course of time, but for now, I've made it so that when you
post such a change, you'll see an old-school deleted file and an added file,
even when the Review Board server supports moved files.

Testing done:
* Posted a variety of shelved changes with different types of changes contained
  within.
* Ran `rbt diff N` with a shelved changeset, which is what prompted the
  addition of the options to that command.
* Ran unit tests.

Fixes bug 2044.

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