Possible feature contribution: Detect 'risky' packages whose names present in local directory.

**Background:**
Here is a simple directory tree for illustration purpose.

.
├── script.py
└── wandb

In script.py. I have a line to import _wandb_, `import wandb`.
When I execute _pipreqs_ on **./**, it lists all packages but _wandb_. I guess it is due to _pipreqs_ believes _wandb_ is not an external dependency because of its presence in the directory. Perhaps it is recognised as a locally developed package.

However in this case, given _wandb_ is a prevailing external package for deep learning **and the local _wandb_ folder is empty**, it can be deduced that _wandb_ is bound to be an external dependent. In fact, I think it is common that folder / file in the directory shares same name with some external packages. In such case, those packages will not be detected.

**Trouble shooting:**
`packages = imports - (set(candidates) & imports)`
The case is due to the above line in function _get_all_imports_ in pipreqs.py. Since _wandb_ is the intersection between _candidates_ and _imports_, it is finally eliminated from _imports_

**Solution:**
I believe that elements like _wandb_ in this example are identified as **risky**, because they are not only registered in PyPI, but also filed locally. They should not be added to requirements.txt directly, which I totally agree. However, is it possible to add a feature to identify those risky packages and output them to another file? Additionally, printing debug info can also be considered.

If this idea is reasonable, I can contribute on that.

Start in pipreqs.py at get_all_imports, especially the packages calculation shown in the issue. Review how candidates and imports are collected, then determine how risky packages should be represented and where optional output or debug information would belong. Done means the proposed behavior is defined and covered for a local directory sharing a package name.

Written by the indexing model from the issue text.