Issues within the language module architecture

[tsaglam]

This issue is meant to collect problems with the design of the language modules.
Known problems are:

• The name frontend is not very good, as they are technically not frontends but rather language modules for parsing and tokenization.
• The token constants should not be constants in an interface with manually defined IDs, they should be enum literals in an enum, where each language should have its own enum and the ordinal is the ID.
• The common tokens FILE_END and SEPARATOR_TOKEN should not be identified via the index but rather via methods in the token enums (prescribed by a common interface which should be part of the front-end utils).
• Most frontends will not need their own token classes, except the emf frontend.
• The language interface should offer default methods for method signatures that are often implemented the same way (e.g. usesIndex() with false, isPreformatted() with true)
• Language.parse() should return a result object with both the tokens and the error status (as suggested below)
• Language modules should provide readme files that explain the design rationales of the token extraction.
• An abstract parser class should offer shared functionality among frontends
• The parser should be instantiated per submissions not globally per language.
• The language facades should not be named the same (API-breaking change!!!)

[Alberth289346]

// submission.java line 258
        tokenList = language.parse(submissionRootFile, relativeFilePaths);
        if (!language.hasErrors()) {

Just passing by, saw this issue, remembered the above interface weirdness.

It's parsing a submission, and you get the token list. Then separately you must query the error status.
I think a better solution is to pass both back together from the parse call by wrapping them into an class or so.

[tsaglam]

Some of these issues are currently being addressed by @JanWittler, his PR will follow soon.

[tsaglam]

Suceeded by #983.