virtualenvs remember the prefix of the python that created them and do
magic to load packages from them; help them remember a more durable
path.

`virtualenv_install_with_resources` will now attempt to guess the
desired Python based on the active build options and based on the
dependencies and requirements. When the situation is ambiguous (e.g.,
`depends_on :python3` and `build.with? "python"` is true) raise
`FormulaAmbiguousPythonError` unless `:using => "python"` or
`:using => "python3"` has been passed to resolve the ambiguity.

In most cases, this will allow

```
    virtualenv_create(libexec, "python3")
    virtualenv_install_with_resources
```

to be changed to just

```
    virtualenv_install_with_resources
```

`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).

* python: tweak script linking in virtualenv

Instead of making the formula author use a slightly awkward block like

  venv.link_scripts(bin) { venv.pip_install buildpath }

avoid exposing this implementation detail and offer the more familiar:

  venv.pip_install buildpath, :link_scripts => bin

* Add non-block form and use instead of recursion

* Update 'pip_install' documentation

* Remove obsolete 'link_scripts'

* Add test for 'pip_install' with linking scripts

Also drop no longer relevant (and broken) `link_scripts` test, that
served as a template for the new test.

* Restore compatibility with Ruby 1.8.7

* Replace option hash with 'pip_install_and_link'

* Avoid confusing 'Object#tap' and fix silly bug

* Avoid side effects in mock object parameter check

* Simplify argument check (no need for a block)