Upgrades rubygems for 1.9.1: 1.3.5 -> 1.3.7
fix exit status of install with verbose
bump versions to 2.1.0
Merge pull request #313 from hsbt/bump-versions-210

bump versions to 2.1.0
Merge pull request #310 from znz/fix-exit-status-of-install-with-verbose

fix exit status of install with verbose
ruby-build 20130225
Build a shared openssl to link to Ruby as a stopgap to fix build issues some people are having, pending understanding why static linking isn't working.
ruby-build 20130226
Default Ruby CFLAGS to `-Wno-error=shorten-64-to-32`; don't set `CC`

Ref. #290, #311
Feature detection for `-Wno-error=shorten-64-to-32`
Merge pull request #252 from jessedearing/upgrade_191_rubygems

Upgrades rubygems for 1.9.1: 1.3.5 -> 1.3.7
ruby-build 20130227
use --continue when downloading tarball
keep source tarball if '--keep' or 'tar xf' fails
`rbenv install 1.9.3` lists matching definitions
Merge pull request #326 from quark-zju/keep-downloaded-tarball

Keep downloaded tarball sometimes
add jruby-1.7.4-dev
Updated README.md to use https to clone ruby-build
Merge pull request #336 from rkh/jruby-dev

add jruby-1.7.4-dev
Better target the shorten-64-to-32 workaround (#325, #319)

The previous version of this logic was causing us to
pass the flag when
 * clang is on the PATH, and
 * $CC, or 'clang' if CC unset, accepts the flag.
But this is totally wrong if we have clang installed,
haven't set $CC, and are going to end up using gcc.
We end up passing the flag to gcc, which rejects it.

The real fix is to put this in the autoconf goo in MRI
upstream -- the only correct way to decide whether to pass
this flag is after we know exactly what compiler we're using
and can test if that compiler accepts the flag.  But we can
do better than before by approximating autoconf's choice of
compiler as $CC if set, 'cc' otherwise (which will typically
be a symlink to gcc or clang or another.)

Fixes: https://github.com/sstephenson/ruby-build/issues/319
  and #325, which is a dupe.