Restructure the project to support the development of separate tools

[korthout]

In order to support the addition of other tools (like #7 and #26), the project should be restructured.

The project currently known as Cantis should be renamed to something like cantis-javaparser. This allows adding other tools, like parsers for other languages (like cantis-dotnet, cantis-scala, etc), visualisers (like #26) and integration tools (like #7) that can use the output of these different parsers. The cantisfile.json outputted by the parsers can be used as the common notation for all of these tools.

To do this, a decision needs to be made on whether the different projects will be hosted in a mono repo or in separate git repos. This question revolves about usability and maintainability. For example, should the tools be released together or separately? After that a bunch of changes need to be made.

In any case:

• [x] Add a warning note to the readme about this change, it may cause build problems
• [x] Rename the maven project to cantis-javaparser
• [x] Reconfigure CI tools to use the new structure
• [x] Split the readme for the main page and the javaparser
• [ ] Set-up or rename the maven central release repo
• [ ] Build a simple visualiser like #26
• [ ] Possibly release a new version of both tools together

In the case of a mono repo:

• [x] Move the maven project and associated files to a separate directory within the repo
• [x] Perhaps some build tool is required to build/release each of the tools together or separately. This build tool should be able to deal with a polyglot system

In the case of separate git repos:

• [x] Rename the GitHub project to cantis-javaparser
• [x] Create a GitHub project for cantis to have some main project with info

[korthout]

Mono repo:

Pros	Cons
Only 1 place for issue tracking	Separating pipelines for each project will be difficult -> Requires PoC
Only 1 PR per feature, even when crosscutting over multiple projects	Separate releases are required (polyglot projects), but releasing different tools in one Github project may pose problems
Easy to find all related projects	Longer build times (sum of build times of all projects), unless these can be parallelised
One readme explaining the goal of Cantis
Integration tests crosscutting all projects

[korthout]

50 shows that it is possible to create separate pipelines for each sub project (package). These jobs are executed concurrently (parallel). And each can build packages in a language of their choice (polyglot). Successful PoC, so I will continue with a monorepo.