Just using paths relative to ${BASH_SOURCE} to access `libexec`
fails if the scripts are symlinked to a location,
such as when installed with Homebrew,
since the `libexec` directory is not linked into `brew --prefix`.

Implement a simple version of `realpath`
and run `${BASH_SOURCE}` through it.
This gets the actual installation directory
relative to which `libexec` is located.

Co-authored-by: Andrew Christianson <achristianson@edmunds.com>

pyenv-virtualenvs could not list conda environments & pyenv shell would only activate the base conda environment
the conda detection criteria of testing the presence of `conda` or `activate` files under `$(pyenv root)/versions/$version/bin` appears to be the culprit, since newer environments no longer include these files: those files reside in the base conda environment
- add detection criteria of `$(pyenv root)/versions/$version/conda-meta`
- compute the real prefix to the base environment from `realpath $(realpath $(pyenv root)/versions/$version)/../..`
- to allow that, enhance substitute `realpath` in `pyenv-virtualenvs` to reduce relative paths `.` & `..`, and factor that code out to a file under `libexec` for reuse
- hook `which` to locate conda from the real prefix

conda's environment might not have `python` executable. If the prefix
doesn't contain `python` in it, `pyenv-which` might be ran into infinite
loop if some of `which` hooks invoke `pyenv-virtualenv-prefix`.