The Manual Updates pages were written back when Review Board was still
installed through an SVN checkout and custom configuration files. They're
more confusing than anything these days. This change fixes that.

First, the pages look less ugly now. The text is more readable, and there are
page headers and margins. The gold box with the initial instructions no longer
points people to an old wiki page, and we don't talk about "recent changes"
but rather "upgrades."

The very misleading page talking about syncdb has been removed. People would
hit that with all sorts of database errors, and our instructions were almost
always wrong. The page was originally written to catch the case where people
upgraded, got the "new" ChangeDescription model, and would later on crash when
something tried to access it. Even worse, it would talk about running
"./manage.py." Not only should people use rb-site, but "./manage.py" isn't
even correct in a source install anymore.

What we have now is an initial query for a SiteConfiguration. If it fails for
any reason, we display a page saying there may be a database error. We give
some useful hints and then show them the database error. It should tell them
if tables are missing, if there are connection issues, or if the database is
locked. This will of course be database-specific.

We now check the running version and compare it with the last stored version
from the previous site install/upgrade. If they don't match, we tell the user
and give them instructions on fixing it. The page knows if it's a developer
checkout vs. production install, and gives the appropriate command lines
to fix the problem. On developer installs, we will hit this after version
bumps, until we do a syncdb.

The data directory is another problem area for people. We try to give
instructions at the end of rb-site install/upgrade, but people don't always
read them. Now we check for the directory's existence and whether it's
writable. If the directory isn't what we expect, we tell them (helping in the
case of $HOME pointing to something like /var/www). We give instructions
on fixing $HOME on Apache, fastcgi, and wsgi. And we give instructions on fixing
permission problems. All paths and usernames are picked up from the system,
and should in most cases be correct.

Tested each of these on a developer install and a site install, with each
combination of problems.