Don't auto-deactivate venv if it's not a project

[cecep2]

Uff, I just realized that #209 introduced a rather unfortunate bug: when I just want to activate a venv that is not connected to any project or has an activation file ( vf activate testvenv), #209 will immediately deactivate the venv when changing the directory (because it's not in $PROJECT_HOME). To fix this, I now also check if $VIRTUAL_ENV is in vf lsprojects

[cecep2]

One detail to add: This is still an imperfect solution. If I connect my project in $PROJECT_HOME to a virtualenv using an activation file, the virtualenv of this project might not be auto-deactivated IF I activated it with vf workon project. This is because:

a) switching into project directories with vf workon project doesn't set the VF_AUTO_ACTIVATED flag, that only happens when the cd command is used
b) the virtualenv specified in the activation file might not have a corresponding directory in $PROJECT_HOME and with this patch we only auto-deactivate if $VIRTUAL_ENV is in vf lsprojects

I think a more complete solution would require changes to the projects plugin where we could set something like a PROJECT_ACTIVATED flag that would be checked in the auto-activation plugin, but I remember that a similar proposal was rejected earlier because it's problematic from a "principle of least astonishment" perspective. However, for me personally the solution here is 'good enough' since I don't use activation files for projects stored in $PROJECT_HOME.

[justinmayer]

@cecep2: Many thanks for the fix. I don't recall the previous discussion, but I'm not opposed to us divining a more elegant solution at some point down the road.