[FEATURE] Internal virtual environment support

[kjczarne]

Is your feature request related to a problem? Please describe.
General purpose automation systems like nox or tox have a way of creating a virtual environment in the background. Adding a similar functionality to Kalash would mean that test suites can depend on specific versions of packages.

Describe the solution you'd like
I would say creating a venv should happen by default and we should have a --no-venv flag when you want to run with the base interpreter.

Describe alternatives you've considered
There are two alternatives:

• Keep venv creation up to the user - not ideal, would force QA Engineers to create full-on Python packages. From experience I know they rarely want to create valid Python package setups for hardware tests.
• Flip the default behavior around - use base interpreter by default and have a --venv flag.

Additional context
In any case we should elect not to modify the base interpreter packages and just warn users about version mismatches for the packages. Kalash should not modify the existing setup in any way, unless it uses a self-managed virtual environment.

[pprol]

I would suggest, use base interpreter by default, and if somebody wants to use an specific environment, let the user decide it. Maybe could be added in the .yaml file? Something like "env-packages: something, other...", like dependencies for the virtual environment.

[kjczarne]

The intention is to list the packages in the YAML file under the config section. Something like:

config:
  venv:
    packages:
      - 'prost==2.0.0'

Maybe we do as you suggest, so as not to break the current API for the users. I will move this to the 4.1.0 Milestone then, since it would not break the current API if we go this route.

[kjczarne]

Pulling this off of the 4.1.0 milestone. Similar solutions can be currently done with projects like pipenv and this is definitely of a very low priority in that context.