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.
This makes me wonder if specifying `1.9.3` pins us to an exact version; where did you find the documentation that `1.9.3` defaults to `1.9.3-p545`? I'm curious to understand how that works.