Previous to this commit, backups were tied to the git revision (SHA1) of
the app at the time the backup:create command was invoked. If the SHA1
at the time of restore was different, the script would refuse to restore
the backup.  This commit loosens this tie so that the backup script only
complains if the value of the Gitlab::VERSION constant is different
between the time of backup and the time of restore.

These fixes will allow a restore of gitlab when the backups and
repositories directories are in non-standard locations (ie sub-dirs
of gitlabhq).  Also allows the restore to be run from script
overriding the need of a user to confirm the rebuild of the
authorized_keys file.

If the backup directory is not sub the gitlab install directory,
then the git rev-parse call will fail.

Uses ActiveRecord::Base.connection.quote_table_name.
Fixes issue 2437.

Rename gitlab:app:db_* to gitlab:backup:db:*
Rename gitlab:app:repo_* to gitlab:backup:repo:*
Rename *_dump to *_create

In backup_create, backup information hash is using symbol as its key.
But in backup_restore, string key is used and it returns empty value.

Merge branch 'master' into non-interactive-aws-install

Conflicts:
	doc/installation.md

Fix merge mess in installation.md

New config option: git_hooks_path

Modified the `repo_dump` and `repo_restore` rake tasks to properly dump and restore repositories based on their `path` rather than their (project) `name`. The project name can be uppercase and may contain spaces. This caused the repository to be restored as a different `path` that it was initially created as, thus, breaking the `git remote` and the web interface can no longer detect the repository either because it searches by `path` and not by `name`. Also, when restoring the permissions are incorrect making it impossible to push new commits to the remote repository. So now on success it'll set the correct permissions (but requires that the `gitlab` user has `sudo` privileges, or this task must be executed as root).