Use rbenv to force a decent version of Ruby 1.9.3

Ruby 1.9.3 has a bug in [Psych](https://bugs.ruby-lang.org/issues/6487)

This manifests itself on the default version of ruby available as `/usr/bin/ruby1.9.1` on our CI machines. Compare:

```
jenkins@ci-slave-2:~/workspace/vcloud-core-broken$ ruby -e "require 'psych' ; puts Psych.load_file '/dev/null'"
/usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': no implicit conversionfrom nil to integer (TypeError)
    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'
    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'
    from -e:1:in `<main>''
```

```
[gds/vcloud-core:broken-api-token●]$ ruby -e "require 'psych' ; puts Psych.load_file '/dev/null'"
false
```

We hit this bug in our CI tests as described in the [pivotal story](https://www.pivotaltracker.com/story/show/75357174)

By setting `1.9.3` in `.ruby-version` we make our tests run on a ruby managed by rbenv, which will default to 1.9.3-p545 which does not have this bug.

However we also need to rebuild the cached gems in bundler, because they have been built with a shebang of ruby1.9.1 which is not managed by rbenv so will always be the system ruby. In order to do that nicely, I've checked in jenkins_tests.sh if there are any binstubs with ruby1.9.1 in them and if so, wiped the gem cache, which will slow down the first build. Hopefully the addition of `--shebang ruby` to the
bundle install will do the right thing and it will only be the first build that is slow.

Once this is merged, we can then revert the revert done in #99 and the new test will hopefully work.
From the [rbenv documentation](https://github.com/sstephenson/rbenv#locating-the-ruby-installation):

> Version names to rbenv are simply the names of the directories in ~/.rbenv/versions.

So I guess it just depends on what our CI machine has installed.

I think it's better to be explicit if we're relying on what we have configured on our CI machine, since we're pinning to just one version anyway.