refactoring: split python code into classes + utilities + tools

[lukasrothenberger]

The current state of the library needs refactoring. I propose to refactor to the following structure:

• root
  • tools
    • explorer
    • optimizer
    • ...
  • cli
    • discopop (e.g. via https://gist.github.com/amarao/36327a6f77b86b90c2bca72ba03c9d3a)
    • explorer
    • optimizer
    • ...
  • utilities
    • LineMapping
    • PathManagement
    • ...
  • classes
    • patterns
      • ...
    • graphs
      • PEGraphX
      • ...
    • result_classes
      • ...

[goerlibe]

Seems good 👍
One suggestion: We move all the command line stuff to a separate directory/package/... .
→ The top-level directories would then be: cli, tools, utilities, classes
Currently the cli functionality is already well-separated from the actual implementation but the separation is not really visible as the files all reside in the same directory.

We could even take it even one step further and have completely separate packages for each tool. e.g.

main package for a "standard installation"

• discopop (requires all the cli packages. Installing discopop therefore results in a "full" installation of everything)

cli packages

• discopop-explorer-cli (requires discopop-explorer)
• discopop-optimizer-cli (requires discopop-optimizer)
• ...

pure python packages that provide the python APIs

They each require the discopop-common package, if needed. If a component is however only needed in one package then it can reside in the respective package.

• discopop-explorer
• discopop-optimizer
• ...

all the shared stuff goes into discopop-common

• discopop-common
  • utilities
  • classes

In theory this would make it possible to install only the tools needed for the job at hand (+ discopop-common), e.g. if a user is not interested in the optimizer or the patches, only the discopop-explorer(-cli) would need to be installed.
While this is not really a common use case, it would force us into separating concerns more strictly, making the code more reusable and easier to understand.

A downside I can think of: having separate packages for each tool would require us to make sure that installed versions match properly. However this is also something I would also like to see from the VSCX perspective. Currently there is no check to ensure that the installed discopop version is compatible with the VSCX extension. I feel like a notification should show up during startup to let the user know if the (oftentimes automatically updated) extension is intended to work with a different discopop version.

PS:
The discopop-profiler is completely outdated and can be removed, right?