Support parallel-installed Django eggs

If a system has different versions of Django installed as separate eggs (such
as having the latest version as well as an older version for compatibility with
ReviewBoard), this addition to the WSGI loader enables it to find the matching
supported version on the system.

This will also make things easier on distro upgrades, as it will be possible to
have both the Django 1.4 egg on the system with Review Board 1.7.21 and Django
1.6 in place for Review Board 2.0

A release note will be needed for existing sites, as if they want to support
this capability, they will need to update their reviewboard.wsgi file manually.
This patch will take affect only for new installs.

Testing Done:
Installed the prototype parallel-installable Django 1.4 package on Fedora 20:
http://toshio.fedorapeople.org/django/python-django14-1.4.8-1.fc20.1.src.rpm

Verified that ReviewBoard starts properly. It failed without this patch.

Reviewed at https://reviews.reviewboard.org/r/5520/
Merge branch 'release-1.7.x' into release-2.0.x
User manual part 2.

This change updates some of the text and replaces all of the screenshots for
the getting-started/, dashboard/, and review-requests/ directories in the user
manual. As part of this, I've pulled in the retina_images extension, which
lets us have @2x versions of our screenshots.

Testing done:
* Built HTML docs
* Checked that @2x images were included in the _images directory.

Reviewed at https://reviews.reviewboard.org/r/5541/
Fix move detection for the last line in an insert group.

The move detection introduced an off-by-one where the last line in a
chunk wasn't being processed as a move unless the line after the chunk
had content. That last line should never have been processed either
in the first place, but we were just looping too hard.

We now loop only through the lines in the chunk, and if we've hit the
line and have any move ranges calculated, we process them.
Fix showing indentation changes on interdiffs in partly-invalid chunks.

When generating interdiffs, we figure out which chunks we actually want
to show any change information for, restricting it to chunks matching
the ranges indicated in the actual diff files.

The problem is, the way this interacts with "equals" computation (where
we strip two otherwise "equal" lines) can cause indentation information
to
be filtered out. This happens because any chunk that isn't completely
within a valid range will get filtered out. Even though an indentation
change is an actual change line, we make it appear as an "equal", which
appears to span beyond those ranges.

To fix this, we needed to break up any chunks sitting on a valid range
boundary, keeping those parts of the chunks and turning the remains into
a filtered-equal chunk.

We then needed to convert the "filtered-equal" chunks to "equal" and
stitch those back together into "equal" chunks later. We already had
processors to do both of these things, but the one for merging adjacent
chunks happened right after interdiff filtering (which was too soon). We
now do this and convert back to "equal" in the post-processing meta
stage. At this stage, we also know about indentation information, so we
can also single those out as their own chunks, sanely.