I was seeing the following occasionally in scripts:

> …/.pyenv/libexec/pyenv-version-file-read: line 12: type: write error: Broken pipe

This patch hopefully improves/fixes this, and it seems better anyway to
just use sed here.

When we started to support reading `.ruby-version` files, we made a
commitment to not support fuzzy version matching. Treating "ruby-2.1.5"
as "2.1.5" is a sort of fuzzy matching, so we put in place a warning
telling you to remove the extraneous "ruby-" prefix popularly used by
other Ruby version managers to denote MRI. (Their logic is that MRI is
"ruby" and other rubies are not "ruby", apparently.)

However, people are often not able to remove the prefix in their
projects because they want to support other coworkers and tools that
sadly still require the prefix, like RubyMine.

So to restore sanity for a big portion of our users, the warning is gone.

Display the other available ones still.

Fixes https://github.com/yyuu/pyenv/issues/291

This is a follow-up to de5c61c.

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

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

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.

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

- e4cbf04592
- 3ee395f9b5

This implements removing of the shims path element via bash
substitution, instead of jumping around in all the `$PATH` elements.

Running any shim (and thus `rbenv-exec`) would always execute
`rbenv-version-name` twice: once in `rbenv-exec` and another time in
`rbenv-which`, even though RBENV_VERSION variable would have already
been populated at this point.

Now RBENV_VERSION is respected within `rbenv-which`.

It's slow and not necessary since we expect `$0` to already be expanded.

In tests this change forces us to deal with some relative paths, but
it's not a big deal. The `rbenv init -` output in the most common case
will be the same as before:

    source '/home/myuser/.rbenv/libexec/../completions/rbenv.bash'

This speeds up every `rbenv` invocation significantly.

On systems that support both C compiling and dynamic loading, we can
speed up `realpath()` (where most time in rbenv is spent) by replacing
it with a dynamically loaded bash builtin.

When `make -C src` is called in the project's root,
`libexec/rbenv-realpath.dylib` will be created. If it exists, rbenv will
attempt to load it as a builtin command. If it fails, execution will
fall back to the old `realpath()` shell function.

With e.g. /usr/local/bin/.python-version owned by some user, `pyenv
local foo` would fail, if the user has no permissions for
`/usr/local/bin`, but only the `.python-version` file.