Implement pyvenv-tracking-mode

[dalanicolai]

The pyvenv-tracking-mode changes the virtual environment on changing focus
between buffers.

[dalanicolai]

Let me elaborate a little on the changes implemented in this PR. Currently (before this PR), when working on two multiple different python projects using multiple different virtual environments, Spacemacs does not automatically switch the virtual environment when switching between buffers of the different project (at least not when using the pyvenv functionality).
The documentation says that after creating some .venv file, pyvenv will automatically set the environment when visiting a buffer, which is not accurate. It only changes when visiting a file (NOT when visiting only a buffer). So when opening a different file from a different project, then the virtual environment will change and it will NOT change back to the right environment by going back to the buffer of the former project. This still has to be done manually (in 2020 ;)
Now the pyvenv package provides functionality to automatically change (follow with) the virtual environment when changing focus to a different buffer (but this functionality has/had not been implemented in the python layer). However, that functionality requires two local variables to be set in the buffer, as documented in the pyvenv-track-virtualenv docstring on line 423 in pyvenv.el. Also it requires the pyvenv-tracking-mode to be activated (see line 412 here).

So I have updated the layer to fulfill these requirements. Additionally, I have updated the documentation accordingly.

[smile13241324]

Thanks for the detailed explanation, I was originally confused by the change from "if" to "cond" statements to be honest. Now after a more detailed look I can say I like your change and will merge it today.

[smile13241324]

As to your remark about 2020 @dalanicolai yes indeed emacs has a lot of old code which becomes older by the minute, my primary strategy against this is removing as much of poorly maintained elisp code and replace it with language dependent LSP server solutions which are maintained by all IDE manufacturers.

This should also make us free to invest more time into new features instead of bug fixing broken packages. If you happen to stumble about non working packages in a language you are working in, please mention me. Right now I have the feeling we have far more exotic packages not working in the layers than we are aware of.

I have got a similar remark from a fellow gopher about the entire go layer not longer working without gopls (LSP) since Google made gomodules the default mode for the runtime.