#158: MVP level 2 for language agnostic templates

[hohwille]

Adresses/Fixes #158 Extends PR #1634

New features of MVP level 2:

• Track and collect import statements
• Expose generatedType (currently as faked type) to model (allows generators to see what types have imports and do not need to be fully qualified)
• Avoid manual registry for CobiGen generators by resolving them from imports.
• Support for @CobiGenDynamicType annotation and replace annotated type with result of generator

@devonfw/cobigen

[hohwille]

I also close this PR as replaced by #1636 However, I still see the need to decide if we want to stay with CobiGenOutput and CobiGenCodeBlock API and decide against mmm-code. I am fine with this, but we should discuss the pros and cons. What I like of the new light approach is that it means much less maintenance effort and is even more flexible for outputs that are structured but not really programming languages that have classes/types, imports, etc. CobiGenCodeBlock can be pretty much anything - it is just a marked section within a generated file (or even in input). It can also be the body of an HTML file, etc. I assume that for the 80% case we are fine with this. In case we want to support very sophisticated and advanced stuff (e.g. do annotation processing inside a generator to influence the generated output) then IMHO there is no other way than mmm-code. However, we could even consider improving the "light" Java parser that I hacked over the weekend to be much more reliable and consider allowing CobiGenCodeBlock to optionally carry more semantic structure, so we could use it as input reader and get rid of the byte-code dependency in CobiGen, we could even remove mmm-code entirely from CobiGen. However, finding arbitrary source-code from a project would be very tricky. If we stick to the input that is selected by the end-user, we could simplify massively and thus also get independent of the build-tool maven and also get much faster without classpath scans, etc.