heroku-buildpack-ruby

Set GEM_PATH instead of vendoring Gem

A "double rainbow" deploy is when someone is using the same buildpack twice. Normally this is by accident. There are failure conditions defined in #511 the app has to have a `json` gem and a version of Ruby that is different from the version of Ruby being used by the buildpacks.

When this happens, this exception will occur when the second buildpack tries to execute:

```
remote: -----> Ruby app detected
remote: /tmp/tmp.Se0nOtPeri/bin/ruby: symbol lookup error: /tmp/build_c85cc44940028913e25caa54b9ff2142/vendor/bundle/ruby/2.3.0/gems/json-1.8.6/lib/json/ext/generator.so: undefined symbol: rb_data_typed_object_zalloc
remote:  !     Push rejected, failed to compile Ruby app.
```

If you look at the output, the failure is happening extremely early, this indicated that it was happening before any significant code had been run, otherwise we would have expected to see

```
remote: -----> Compiling Ruby
```

The exception only occurred when using `v155` of the buildpack as the second buildpack (via `heroku buildpacks:add`). 

Here's what was happening: The first buildpack runs and installs the app's `json` gem. The buildpacks are designed so that they make their contents available for the next buildpack. I.e. if you install `node` via a buildpack, then the next buildpack to execute is expected to have `node` on the `PATH`. The same is true of ruby and any gems installed.

So now the second buildpack executes. To do this it's own source code is loaded into memory, when it does this it hits a `require "json"` call that was introduced in `v155` and tries find the `json` library. While this library ships with Ruby it is also a gem, if the gem is present on the system it will prefer the gem. So it loads the `json` gem from a different version of Ruby that is currently executing, it can't because the symbols are different, it errors out.

We can avoid this by forcing `GEM_PATH` that the Ruby buildpack is using to the default for the current Ruby version.