Don't crash when upgrading from pre-5f0389f (SMTP install.py args)

Before this fix, if you upgraded from a Critic version that did not
support --smtp-* command line arguments in install.py (i.e. before
5f0389f) to a Critic version with such support, the upgrade would
crash because it tried to read, for example, arguments.smtp_use_ssl
in the installation/smtp.py prepare() step.

The fix is to only read arguments shared between install.py and
upgrade.py, unless a mode == "install" check has been made.

The crash can be reproduced by upgrading from 30c4f10 to 25071da.
Install symlink if something is a symlink in git

Before this fix the installer would install two identical copies of symlinked
files, one named as the symlink and one named as the symlink target.

For example in fa5971e it installed jquery.js and jquery-1.7.1.min.js
(two identical regular files).
Sort migrations according to initial commit date before running

When upgrading over really large spans of commits one might be executing
a large set of migration scripts and in this case the execution order of
these are critically important.  This fix makes sure the migration scripts
execute in the order that they were originally added to the Critic git
repo.

An example of a bug caused by wrong migration script execution order can
be seen (along with other issues) in the upgrade from 30c4f10 to 25071da.
The two migration scripts that have an order dependency in this case is:

preference.commit.diff.rulerColumn.py (added 2013-04-08) which adds a
new pref and lists default_integer in its INSERT query, and then
dbschema.per-repository-or-filter-preferences.py (added 2013-07-10)
which deletes the default_integer column in preferences.
Fix out-of-repo symlink hashing

Critic currently uses "git hash-object" when finding the content hash of a
installed file (i.e. /usr/share/critic/whatever.py etc), and on the git repo
side it uses "git ls-tree".  This works well if the target is a normal file,
but it doesn't work if the installed target is a symlink.  This is because
git hash-object will follow the link and hash the content of the file that
the link points to, whereas "git ls-tree" returns the content hash of the
symlink itself.

"git hash-object" currently has no switch that instructs it to hash the link
itself when given a symlink.  Because of this we need to manually compute the
content hash of the symlink, in such a way that it matches the hash returned
by "git ls-tree".

Before this fix, when Critic was running an upgrade where a file pointed to
by a symlink changed (e.g. jquery.js), it would incorrectly say that "the
file has changed since it was installed" and ask the user for confirmation.

Such an issue can be seen in the upgrade from 30c4f10 to 25071da, after
various other issues is worked around.
Specify what is OK when it's OK
Don't commit db transaction setting new installed_sha1 for upgrade dry-run