The tasks gitlab:env:info mixes user and group, and presume as a group 'git'.
However, gitolite group name can be anything.

That patch add the git group name in the config,
and check gitolite.ssh_user group against git.group
(which defaults to 'git', as before this patch, if undefined).

M config/gitlab.yml.example:
  Add 'group' in 'git' section
  Mention default value for the two extra settings
M lib/tasks/gitlab/check.rake:
  Check that gitolite.ssh_user *group* is the one defined in git.group.
  Make sure to default to 'git' as the expected group
    if said group is undefined in the config.
  Note: uses a more complete regexp for the group detection
        (the group can start, end or be in the middle or the list of groups
         of gitolite.ssh_user)
M: config/initializers/1_settings.rb:
  Add default values for gitolite.group and gitlab.user

All overrides are marked as deprecated.
Default settings are at the bottom.

Rewrite build_url, use web_protocol for repo indicator.

Explicitly initialize custom port to make the logic obvious.

Should no longer freak out when omniauth settings aren't present in
gitlab.yml. People who aren't using it shouldn't even have to put a
'false' entry in their config for it (and probably wouldn't, after an
upgrade).

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

Conflicts:
	doc/installation.md

Fix merge mess in installation.md

New config option: git_hooks_path

Closes #1237

of 'gitlab.yml'.

gitlabhq\config\initializers\1_settings.rb looks for
'gitolite_admin_uri' in the 'git' section of 'gitlab.yml'

Actually, that setting is in the 'git_host' section.
If not fixed, the 'gitolite_admin_uri' would always be equals to
'git@localhost:gitolite-admin', even if the administrator wants
to have another user than 'git' in charge of that repo.