Add option for using shared python packages

Some libraries, like `pip`, `setuptools` and `wheel` are almost always needed for a virtual environments. Also, these tools should be kept updated for their latest version. I addition, some users might want to always install some debugging / linting tools to new virtual environments.

### Proposal
Add and option to `venvlinkrc`, like `shared_packages`, that should be empty or a list, like `[pip, setuptools, wheel]`. The `[pip, setuptools, wheel]` could be default, since probably at least these tools are needed for >90% of virtual environments.

This would give users the option to add there other packages they use (I have personal interest on adding `IPython` there, since I use the `IPython.embed()` for debugging. Maybe someone else would like to have `pdbpp` there, or `pylint`, etc.)

### Preliminary working logic

- Packaging libraries ( `pip`, `setuptools`, `wheel`) are installed to a special virtual environment `__venvlink__`, which could be located in the `venv_folder`. This would assume users would not use the special name `__venvlink__` as their virtual environment name (maybe give a warning if user tries to use it).
- Then, these packaging libraries would be added to any *new* virtual environment by adding a special [`.pth` file](https://docs.python.org/3/library/site.html) to the newly created virtual environment (inside `venv_folder`). This is how for example [pipx](https://pipxproject.github.io/pipx/how-pipx-works/) works.
- The packaging libraries should be kept up-to-date. The options are (1) Update to latest every time new virtual environment is created, like pipx does. (2) Update every time virtual environment is created, but only once per day or week, and keep a "latest_shared_libraries_check" timestamp in a special file, for example `venvlinkrc`. This would make creating virtual environments slightly faster, if many of them are created in a short period of time. Perhaps first option would be the included in the first implementation.
- In the future, the could be a "no-update" option like `disable_shared_autoupdate`, where values could be `all` or a list of packages. If even more fine-grained control is needed, the could be some option for disallowing auto-updates for major or minor releases (and allowing only minor or patch releases). This could be something like a list of tuples.

### Other possible implementations

There would be also another way to implement similar outcome: Adding a list for packages in `venvlinkrc` that should be automatically installed for every new virtual environment (`install_packages` or something like that) The difference is that when using `shared_packages`, the shared packages would be only ever needed to install once; this would save some disk space. The outcome would not be entirely similar, so I guess both are needed. For example, if someone would like to always install `numpy` in every new virtual environment but keep the numpy packages isolated from each other (which is the purpose of virtual environments anyway). Therefore, some packages could be shared across virtual environments, and some could be auto-installed. (creating separate issue for that)