Use Bundler.with_clean_env to build without the existing bundle interfering.

When run by the ci-runner, the build commands inherit most of their environment variables, even if some sanitization has been done in lib/build.rb. This is not a problem until the build script try to `bundle install` (with implicit `$PATH`). What happens next is that `bundler` executable becomes confused and throws errors about not being able to find itself (or any other dependency in the project that is not in the ci-runner itself).

This problem has already been reported in gitlabhq/gitlab-ci#83 and gitlabhq/gitlab-ci#38 but the issues were closed because some workarounds (usually involving rvm wrappers) were found to be good enough.

Here is the difference in environment variables between running the `env` build script with the current sanitization code and then with `Bundler.with_clean_env`

```sh
gitlab_run@gitlab:~/runners/gitlab-ci-runner$ diff -u env.vanilla env.with_clean_env
--- env.vanilla        2013-10-27 14:56:40.229681670 +0100
+++ env.with_clean_env 2013-10-27 14:56:50.273682807 +0100
@@ -6,14 +6,12 @@
 CI_BUILD_REF_NAME=master
 CI_SERVER_NAME=GitLab CI
 CI_SERVER=yes
-GEM_HOME=/var/lib/gitlab_run/.bundler/ruby/1.9.1
-GEM_PATH=
 HOME=/var/lib/gitlab_run
 LANG=en_US.UTF-8
 LOGNAME=gitlab_run
 MAIL=/var/mail/gitlab_run
 OLDPWD=/var/lib/gitlab_run
-PATH=/var/lib/gitlab_run/.bundler/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
+PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
 PWD=/var/lib/gitlab_run/runners/gitlab-ci-runner
 RUBYOPT=
 SHELL=/bin/bash
gitlab_run@gitlab:~/runners/gitlab-ci-runner$
```

We notice that the neither the `PATH` nor the `GEM_HOME` variable were sanitized.

This pull request replaces the manual sanitization of `BUNDLE_GEMFILE`, `BUNDLE_BIN_PATH` and `RUBYOPT` by wrapping the child process invokation in an explicit `Bundler.with_clean_env` block.