Dependency with dashed distribution-name is marked as unused if there is a folder with its import name in the repository #505

Describe the bug
When a package with a dashed distribution name (e.g. nats-py) is used in a repository that contains a subpackage with the same name as the import name (e.g. nats), fawltydeps reports the dependency as unused although it is used.

To Reproduce

1. Create a repository with the following structure:

   pyproject.toml  # Project config
   src             # Source folder
    |-- main.py    # Contains the import
    |-- nats       # Empty folder
   

2. Add the following minimal content to pyproject.toml:

   [project]
   name = "test"
   version = "0.1.0"
   requires-python = ">=3.13.2"
   dependencies = ["nats-py"

3. Add the following content to the main.py:

   import nats
   import typing_extensions
   
   print(f"{nats=}")
   print(f"{typing_extensions=}")

4. Initialize a local .venv & verify that the program is working and it correctly imports the package:

   > python src/main.py
   nats=<module 'nats' from '.../site-packages/nats/__init__.py'>
   typing_extensions=<module 'typing_extensions' from '.../site-packages/typing_extensions.py'>

5. Run fawltydeps on the project

   Expected behavior

   No undeclared or unused dependencies detected.

   Observed behavior

   These dependencies appear to be unused (i.e. not imported):
   - 'nats-py'
   
   For a more verbose report re-run with the `--detailed` option.

   Note how the typing-extensions module is not listed

6. Rename the nats folder (e.g. to nuts) & rerun fawltydeps

   Observed behavior

   No undeclared or unused dependencies detected.

   (as expected)

Environment

• Windows 11
• FawltyDeps v0.20.0

Additional context

• Also tested with other packages, nats is only an example.
• This is also not solved via a

    [tool.fawltydeps.custom_mapping]
    nats-py = ["nats"]

  since the import is marked as non-external
• Investigated this further. The problem is how the is_external_import function uses isort.place_module to determine if the module is a third-party module. In turn, the isort function resolves the src dependency here incorrectly and will match the local directory for the dependency instead of correctly identifying it as a external dependency. There is already an issue on the isort repo (FIRSTPARTY/THIRDPARTY detection when --src is specified PyCQA/isort#2429) which mentions a similar issue. Until this is fixed, we either need to have a workaround here (e.g. check the import also via a custom mapping?) or wait for the fix...