Postmodern

Actually `Gem.ruby_api_version` was added sometime in 2.x.

One problem with using API version is lack of separation between 1.9.1, 1.9.2, 1.9.3.

We could wait until 1.9.x is EoLed and then switch to using the API version.

@felixbuenemann gems should be seperated by "version". Allowing gems from 1.9.x versions to mix would add an edge-case to how chruby separates gems. Also, rubygems 1.8.23 will generate absolute `#!`...

If we could somehow query the ruby version (sans the patch-level number) for both 1.9.x and 2.x, that would also work. - Given 1.9.3, gemdir version should be 1.9.3. -...

Er, by patch-level I mean `RUBY_PATCHLEVEL` wrt 1.9.x and the last number in `RUBY_VERSION` in 2.x.

Until rubygems [defaults to using `#!/usr/bin/env ruby` instead of an explicit `#!/path/to/ruby`](https://github.com/rubygems/rubygems/issues/1049), it's looking like separate gem directories for each ruby is the only way.

@wryfi that sounds like a bug in bundler. Double check that the `head -n1 $(which bundle)` points to 2.2.2, and not 2.2.0. bundler _should_ install missing gems into whatever `$GEM_HOME`...

@wryfi see also [gem_home](https://github.com/postmodern/gem_home#readme) for pushing/poping gem dirs.

So we used some [code from RVM](https://github.com/postmodern/chruby/blob/ca8c318146f67c7f6d56f3d050912cb78109b0e4/test/setup#L39-L150) to detect the arch, OS, distro, and then download the precompiled ruby for said platform. Unfortunately, [rvm-binary](https://github.com/rvm/rvm-binary) doesn't always have the most complete...