Closes #1459

infocmp is a system utility that returns information about the user's terminal. When it is shimmed it can cause problems for various programs that use it to determine terminal settings. In particular, the library used by the Scala shell reads it and problems can occur where various control keys don't work (e.g. backspace does not work).

This reverts commit 070e1c859fb2584c3dbe0a6fbe58cbc80938654e, reversing
changes made to 3faeda67bb.

All scripts in libexec/ (excluding pyenv) are called through pyenv,
therefore the shebang lines are not necessary. On some systems this
provides a measurable increase in performance of the shell prompt.

Related to pyenv/pyenv-virtualenv#259

Add `clear` to the Anaconda's default blacklist in order to prevent
pyenv from creating the shim script for it.

The `clear` command executable began included from Anaconda 5.0.0
onwards, and this executable now conceals that of the user's base system
- this hinders the user from running the `clear` command with the
`command not found` error output if a user installs and selects one or
more Python version(s) other than Anaconda 5.x.x.

Adding this one-liner to the blacklist allows the user to use the
`clear` command even when Anaconda 5.x.x is not selected by pyenv.

Add `tput` to the Anaconda's default blacklist in order to prevent pyenv
from creating the shim script for it.

Anaconda 5.0.0 contains some executables which are part of the base
system. Many of these executables did not exist in the last major
version of Anaconda (`4.4.0`), and the existence of pyenv's shim
scripts for these executables in `5.0.0` can cause to conceal those
executables in the user's base system; for the details, please see the
discussion with @yyuu at #992.

This commit resolves a coloured output error when running a terminal
command which uses `tput`. This error occurs when multiple Python
versions are installed alongside `anaconda2-5.0.0` or `anaconda3-5.0.0`
and neither of those two Anaconda versions is selected by pyenv.

`pip -v install foobar` or `pip -q install foobar` did not trigger a rehash before. Now it should have the same behaviour as `pip install foobar`.

The performance issue must be caused by too many I/O requests to
`conda.txt` from fgrep. This inline expansion should work to reduce # of
read to the `conda.txt`.

original performance:

```
% git rev-parse HEAD
4f76be6a12
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash'  0.05s user 0.02s system 76% cpu 0.089 total
```

previous commit: ==> 4x slower than original

```
% git rev-parse HEAD
4469d51ef7
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash'  0.06s user 0.03s system 25% cpu 0.358 total
```

with this workaround: ==> almost same as original

```
% git rev-parse HEAD
3ffe91bdbc
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash'  0.05s user 0.00s system 68% cpu 0.082 total
```

With this, we'd be able to remove a hook script for `pyenv which`
eventually.

Basically I'd like to use system pakcage for `xz` command as much as
possible.

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