Allow setting the X-Forwarded-Proto from upstream load-balancer.

Since 6ad0f7c5762f3e0472a3c43ca883f55abbbb623b it is possible to set `GITLAB_CI_HTTPS=true` without setting environment variables for nginx certificates. In this configuration, gitlab-ci is supposed to be deployed behind an upstream load-balancer that will handle SSL and forwards the requests to gitlab-ci running inside the container.

After setting `GITLAB_CI_HTTPS=true` in my container's environment, I can nsenter into the container and check that the `/home/gitlab_ci/gitlab_ci/config/application.yml` file is setup like this:

```
defaults: &defaults
  ## Gitlab CI settings
  gitlab_ci:
    ## Web server settings
    host: "my-gitlab-ci.example.com"
    port: 443
    https: true
```

Which is correct but not sufficient, because some links are still incorrectly generated with http (not https) scheme.

The problem shows up in different way:
 - the location bar of the browser will show an exclamation mark instead of the expected SSL lock icon (because the page links to non-ssl resources)
 - the javascript on the build page will be broken (it will not render the build output after starting manually a build, only manually reloading the page will show something)
 - the source of the build page includes non-SSL links such as http://my-gitlab-ci.example.com/projects/2/builds/14
 - the build notification emails will also feature non-SSL links to gitlab-ci

To work around the issue, I customized the nginx template in `/app/setup/config/nginx/gitlab_ci` to set the value of the `X-Forwarded-Proto` header to `$http_x_forwarded_proto` instead of the default `$scheme` which is by default http (non ssl); provided my upstream load-balancer sets the header properly this fixes the issue.

This PR allows setting the `X_FORWARDED_PROTO` environment variable to a value other than the default `$scheme`. I recommend the `https` or `$http_x_forwarded_proto` values when running behind a trusted load-balancer.