Support namespace packages

[mknorps]

Loosely related to #44

Python namespace packages allow splitting the subpackages and modules within a single package across multiple separate distribution packages.

https://packaging.python.org/en/latest/guides/packaging-namespace-packages/

Currently, when we want to check a sub-package with FawltyDeps, we need to run the script in a sub-package directory.

We would like to discover namespace packages automatically. Another todo here is to check namespace packages relation to "extras".

This issue is a result of design docs discussion between @tbagrel, @Nour-Mws and @jherland:

[Nour] We are only checking for first level packages (so no modules). Distinguishing modules from packages when multiple packages exist in the namespace is a possible source of headache and deserves more discussion. See https://packaging.python.org/en/latest/guides/packaging-namespace-packages/

Checking that imported modules actually exist in the declared package is out of our scope but is a useful extension. And it seems to be possible with minimal extension to the current solution design but we haven't thought this through, so don't quote me on this :)

[Johan] Even though FawltyDeps only targets the package level (not individual modules), I still think it would be useful to mention modules in this section and how they relate to packages. AFAIU, from FawltyDeps' POV, both packages and modules are "import names", but since FawltyDeps is only concerned with the package level, I guess it would have to either ignore module imports, or resolve them to their parent package?

[jherland]

https://github.com/tweag/chainsail/blob/3e6af8048a2aa0278a59e7c401fa70523f7951fa/app/controller/pyproject.toml#L17 is another example of (mono)repos installing package dependencies by local path.

[mknorps]

We will go back to that once we have an example of a namespace package and the expected behavior.