add a patch to allow building 2.6.9 on osx 10.9

This is a follow-up to de5c61c.

Conflicts:
	plugins/python-build/bin/python-build

README: mention https://github.com/yyuu/pyenv-pip-rehash

doc: use recommended python versions

Import changes from ruby-build v20141028

Warn about #264 in the README

Add Miniconda/Miniconda3 3.7.0 and Anaconda/Anaconda3 2.1.0

SHA256 values generated with direct downloads from repo.continuum.io

As it seems, JRuby 1.7 complains on stderr every time you invoke `system`:

    warning: executable? does not in this environment and will return a dummy value

It doesn't seem to complain when backtics are used. It's safe to use
backticks here because `rbenv rehash` doesn't output anything on stdout,
and the exit status of the command is irrelevant.

Bring rbenv-gem-rehash functionality to core

This bakes in the functionality of rbenv-gem-rehash plugin.

The Rubygems hook is improved:

- It will not rehash for gems installed in locations that rbenv otherwise
  doesn't search for binstubs; for instance in case of
  `bundle --path vendor/bundle`.
- It rescues exceptions and makes them non-lethal by warning on stderr.

This allows rbenv source code to ship with built-in hooks.

Allow installing CPython with `make altinstall` instead of
`make install` with following command-line.

```sh
$ env PYTHON_MAKE_INSTALL_PACKAGE="altinstall" pyenv install -v 3.4.2
```

Install script of setuptools-6.1/pip-1.5.6 will create those links if needed

Add Makefile for 'make test'

Speed up `rbenv rehash`

This was introduced when merging the rbenv upstream change
(https://github.com/sstephenson/rbenv/commit/6bb7f07d2d).

Speed up rbenv by dynamically loading compiled command

It doesn't need to be a bash array and we don't need a separate index of
shims registered. Simply keep everything in a space-separated string and
use that as an index as well.

This assumes that executable names *never* have spaces in them.

On my system that has 25 versions under rbenv, this speeds up rehash
almost 3-fold:

- before: 391 ms
- after:  134 ms

This is achieved by removing duplicate names of executables before
registering them as shims. Since most Rubies will share a lot of the
same executable names ("ruby", "rake", "bundle", ...), this is a
considerable reduction in number of shims registered.

Too many of our users have a shell initialization set up that
inadvertently duplicates some or most of the entries in their PATH,
bringing the system paths again in front of rbenv's shims. If this was a
nested shell (a typical scenario when starting up tmux), `rbenv init`
would get eval'd again but this time, shims won't get added to the front
of the PATH and would only stay and the end of the path, effectively
rendering them useless.

I tried to argue that this is a user problem rather than rbenv's, but I
can't fix everybody shell init when they report bugs. Instead, let's
revert to simpler times in rbenv where we just roll along with the
duplication and don't ask any questions.

This reverts commit 03fa148e81.

Fixes #369

Delegate to `rbenv-shims` instead of `rbenv shims` and therefore skip
going through the main `rbenv` executable again that would set up a lot
of the environment that was already set.

Optimize pyenv-which: implement remove_from_path in Bash

This is the remaining part of
c69d9a1128.

    commit c69d9a1128
    Author: Mislav Marohnić <mislav.marohnic@gmail.com>
    Date:   Mon Oct 13 12:39:47 2014 +0200

        Isolate rbenv-which tests from any `.ruby-version` file on the system

        Having a `.ruby-version` file in any of the parent directories of the
        local clone of rbenv could cause the test suite to fail because it
        wasn't expecting a local version to be set.

This adds the missing parts from the upstream rbenv merge:
f4652fbbf0

- e4cbf04592
- 3ee395f9b5

Having a `.ruby-version` file in any of the parent directories of the
local clone of rbenv could cause the test suite to fail because it
wasn't expecting a local version to be set.

Fixes #533