Don't activate if a 3rd-party venv is activated over ours

The latest release so far (Dec 2023) is 1.2.2, but the version reported is still 1.2.1:
https://github.com/pyenv/pyenv-virtualenv/releases/tag/v1.2.2

Required to build binaries that link against Python.
Carl Meyer, the champion for PEP 0405, has confirmed that there isn't a particular reason why `venv` doesn't do that.

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

Co-authored-by: Jack McIvor <j.mcivor@draftkings.com>

Same as in Pyenv, as it's gone rogue

Prompt removal was never done and is not planned anymore

For example bash-5.1, bash-static.

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>

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

* Adjust tests: update Pip URLs, update expected output to match newer code
* Test library: improve failure message to eliminate the illusion of extra leading space in "actual" output
* Use Bats 1.2.0 like Pyenv
* Install greadlink for old MacOS
* Delete duplicate test

When a fish login shell is invoked within an existing login shell, avoid
duplicating path to the shims by removing existing occurrences before
prepending.

* Fix tests failing after #423

Fix installation steps to allow for Pyenv 2

Fixes #394 - update pyenv virtualenvs to list virtualenvs start with dot prefixes

The text included info on Pyenv startup which is now outdated and incorrect.

Closes https://github.com/pyenv/pyenv/issues/1947, https://github.com/pyenv/pyenv-virtualenv/issues/387

~/.*rc should be modified instead of ~/.*profile

https://github.com/pyenv/pyenv-installer/pull/109

Otherwise, there's no effect for non-login interactive shells