handling for case where unknown option is provided.

- Error handling involves writing error message to stderr, and
  forcefully exiting the init script, forcing user to fix their setup.

- Local testing shows that you get a trivial 1.6x speedup in command execution
  time (over doing `pyenv init -`) by specifying which shell you are using.

to specify the shell they are using when adding:
`eval $(pyenv init - <shell>)` to their config file.

pyenv-init.

- It turns out that the code I wrote was very similar to what was
  already present in rbenv-init.

As rbenv is referenced when I am writing a pull request, I am assuming
that maintainers want code similar to what's already there.

WARNING:
The code will now not validate whether the specified shell is valid or
not, and if you make a silly mistake like writing `--parh` instead of
`--path`, the shell may be set to `--parh` and so forth. But I guess
this is acceptable.

…urce' instead of 'pyenv init - | source'.

The old tests seems to have been copy-paste from some 11 year old
rubyenv setup, and included a long and windy pathname. The old setup was
extremely bad in my view, current test is much better.

Exported variables are local to the specific test, so they will not
affect other test instances.

---> Enables us to remove unnecessary `root` variable in pyenv-init.

… pyenv-init.

echo is a bash built-in, and thus you don't need to launch a new
process for something as simple as writing to stdout.
Saves about 2-3ms.

print_shell_function().

-> Maintainers prefer single quotes instead of double quotes, since it
allows us to look away from tracking what to escape.

Tell users that `pyenv init -` works, but that specifying the shell
which is used is preferable, as it reduces launch time.

Homebrew installations have PYENV_ROOT set to `~/.pyenv`, while the
actual completion file resides in /home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/completions/pyenv.zsh

Thus, if you try to use `$PYENV_ROOT/completions/pyenv.${shell}`, the
completions file will not be found, since you are pointing to:

`~/.pyenv/completions/pyenv.zsh`

when the actual location is:

`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/completions/pyenv.zsh`

This problem is resolved by using the parent folder of the currently
executing file:

`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/libexec/pyenv-init`

which is

`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23`

And then go to completions from there.

I don't like the fact that homebrew installations store some things in
`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/libexec/pyenv-init`

while stuff like `shims` and python versions are stored in `~/.pyenv`, but
that's how it currently is.

In `test_helper.bash`:
set

PATH="${BATS_TEST_DIRNAME%/*}/libexec:$PATH"

instead of

PATH="${BATS_TEST_DIRNAME}../libexec:$PATH"

it essentially enables us to expect

`${exec_root}/completions/pyenv.bash`

instead of something like

`${exec_root}/test/../completions/pyenv.zsh

…\` setup instead of `echo

'`

1) If people are using bash with `set -u` (enable unset variable
   checking), then they will get an error if they run `pyenv` in the
   CLI under the current setup. To avoid any errors when no positional
   arguments, we use ${1:-} instead of $1.

2) We find that the script looks better when using:

```bash
echo \
'pyenv() {
  local command=${1:-}'
```

As opposed to:

```
echo 'pyenv() {
  local command=${1:-}'
```