Add the possibility to point towards the path of the environment to use for inferring package distribution information.

[mknorps]

To be able to test the behaviour of FawltyDeps on real projects and to see the improvement, we need to have a way to define and use an environment different that the FD test environment.

This issue was mentioned by @jherland, @Nour-Mws and @mknorps on many occasions:

• in tests_map_dep_name_to_import_names.py:

  # TODO: These tests are not fully isolated, i.e. they do not control the
  # virtualenv in which they run. For now, we assume that we are running in an
  # environment where at least these packages are available:
  # - setuptools (exposes multiple import names, including pkg_resources)
  # - pip (exposes a single import name: pip)
  # - isort (exposes no top_level.txt, but 'isort' import name can be inferred)
  

• in Incorporating dependency to imports mapping #150

• in slack communication:
  @Nour-Mws

  Thinking out loud: with our current local-dep-to-import mapping, even when Incorporating dependency to imports mapping #150 is merged, it will still be impossible to run fawltydeps in the real projects tests, without installing all the deps defined by a project in the env in which fawltydeps is running?
  In other terms, if we want to separate project x run from project y run, we can't use the current test setup, as they all currently run in the same environment.
  Another thing to note is that since fawltydeps needs to be in the env of the project that it tests, it may be the case that some of the project's undeclared deps end up installed by fawltydeps, and so while for a project declaring pyml, you might have ended with: "I couldn't find pyml in the env, mapping to pyml", you actually find the given package in the env.
  Thoughts?

  @jherland

  True. Also PR Run real worlds projects tests with cmd line tool #147 did change real_projects to run fawlytdeps in a subprocess, and with that we could run it inside a different environment, but we still have to add the functionality to setup those environments and then make fawltydeps run inside them.
  In short, I think there are three different scenarios we could look at here:
  A. FD can only query packages inside the environment it is running. This is where we are, and we really haven't planned on changing that all, yet. (The real_projects work would "simply" be about installing and running FD inside the various test environments.)
  B. Make FD somehow able to switch its execution context from one environment to another. I think this is impossible in general (without switching processes), but it might be possible to e.g. call importlib_metadata.packages_distributions() in a subprocess (than runs inside the target environment). However, this still relies on importlib_metadata being installed in that environment.
  C. It might be possible to configure/customize importlib_metadata to examine a different environment than the current environment. Worst case, we could even write our own version of it. I have not looked deeply into this yet.

[Nour-Mws]

Closed via #219.