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.

Allows for code to be added to the end of the script which will not
mysteriously fail to run for fish shell.

When created on Windows, .rbenv-version or .ruby-version files may have CR characters that will prevent rbenv from correctly parsing the Ruby version. Discard those characters when reading the file.

This greatly improves the performance of `pyenv virtualenvwrapper_lazy`,
which happens to call pyenv-which a lot.

For profiling I've initially used:

    % zmodload zsh/zprof
    % eval "$(pyenv init -)"
    % pyenv virtualenvwrapper_lazy

    Before:
    % zprof|grep -E '(pyenv|virtualenv)'
     1)    1         754,07   754,07   58,95%    751,50   751,50   58,75%  pyenv
    21)    1           2,57     2,57    0,20%      2,57     2,57    0,20%  virtualenvwrapper_setup_lazy_loader
     1)    1         754,07   754,07   58,95%    751,50   751,50   58,75%  pyenv
           1/1         2,57     2,57    0,20%      2,57     2,57             virtualenvwrapper_setup_lazy_loader [21]
           1/1         2,57     2,57    0,20%      2,57     2,57             pyenv [1]
    21)    1           2,57     2,57    0,20%      2,57     2,57    0,20%  virtualenvwrapper_setup_lazy_loader

    After:
    % zprof|grep -E '(pyenv|virtualenv)'
     1)    1         383,30   383,30   27,97%    380,88   380,88   27,79%  pyenv
    31)    1           2,42     2,42    0,18%      2,42     2,42    0,18%  virtualenvwrapper_setup_lazy_loader
     1)    1         383,30   383,30   27,97%    380,88   380,88   27,79%  pyenv
           1/1         2,42     2,42    0,18%      2,42     2,42             virtualenvwrapper_setup_lazy_loader [31]
           1/1         2,42     2,42    0,18%      2,42     2,42             pyenv [1]
    31)    1           2,42     2,42    0,18%      2,42     2,42    0,18%  virtualenvwrapper_setup_lazy_loader

Fixes https://github.com/yyuu/pyenv-virtualenvwrapper/issues/13

finding_local_version_file is extremely slow, when working directory is under the UNC path.
Because //host/.rbenv-version and //.rbenv-version do not exist, but testing them is so slow.
It's the reason to make a serious delay of the response, when the Ruby runs with a current working directory under the UNC path under Cygwin environment.

A response of before applying this patch.
//somehost/somedir $ time ruby -e "exit"

real    0m13.922s
user    0m0.168s
sys     0m0.287s

A response of after applying this patch.
//somehost/somedir $ time ruby -e "exit"

real    0m0.721s
user    0m0.153s
sys     0m0.319s

The `pwd` may return relative path if the `$PWD` is badly declared
in bash/zsh (e.g. `PWD="." bash`). To avoid the infinite loop in
`find_local_version_file()`, stop finding the version file if the
target paths are same consecutively.

This reverts commit 7edceff71ca6aa1281658f6f60ca2e48a6e3f45f, reversing
changes made to 5dea3c9e63.

It seems that "comm" header can't be relied on cross-platform, but that
"ucomm" is more portable. I have no idea whether it's the right value to
use here, but it seems to be doing the job.

Also strip trailing whitespace because OpenBSD 5.4 `ps` output is padded
with spaces for some reason.

Fixes #489

The non-extended regex pattern didn't work on OpenBSD so this switches
grep to extended pattern mode that seems to work consistenty on all
systems.