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.
It's not that I want to pin us to a specific version, rather I think it'd help to be explicit about which versions work. What if it defaults to a version that doesn't include r35766 (as this is open source, we can't be sure about where this is running).

It's fine to leave as-is IMHO if there's no alternative, but if we could specify a minimum version, that'd be ace.