Code clean up and restructure datasploit as a framework.

[upgoingstar]

1. Respective modules in folders. i.e. domain folder contains all modules related to domain OSINT. All these modules execute when domainOsint is used. Same goes for email, IP, username, and file.

2. Specific functions and structure to be used when contributing any module. This will need to be documented.

3. A single command, i.e. datasploit, with multiple switches should be used for triggering any OSINT test.

4. Remove all code repetitions.

As of now @upgoingstar and @KunalAggarwal are doing this. If someone has any idea or would like to join the force, please give us a shout.

[Chan9390]

Putting modules into separate folders is a good idea. But be careful as the code has inter-submodule dependencies. Ex:

• domainOsint.py requires shodanSearch(ip) which is a part of ipOsint.py
• domainOsint.py requires email_fullcontact.py which is a part of emailOsint.py

There are 2 solutions:

• Include the folders and modules in the future release. IMHO this would be a crazy step and increases complexity of module linking
• Remove/resolve the above dependencies and call the module using its main script. Which means: if domainOsint.py wants shodanSearch(ip) it should connect through ipOsint.py instead of direct contact. The advantage is: when you are building a framework, these separate modules become pillars so that documentation and further development becomes easy.

[Chan9390]

Also regarding code repetition, I would suggest you to remove all the main() functions present in separate scripts. Also have the executable mode for the required files i.e. domainOsint.py, 'emailOsint.py` etc. As of now I could see some files having executable mode even though they are rarely used.

[konarkmodi]

@upgoingstar : I can contribute to this too. I have listed few suggestion:

1. Use templates instead of hardcoded HTML. Example do_everything functions. I would suggest something like JINJA templates.

2. do_everything is sequential, we could use some methods to make it async and parallel like Dask etc and makes it scaling easier from one machine to many. Although the there is no use-case of many right now.

3. Use proper loggers instead of print statements in the code.

4. Unit test cases.