Revisit Codegen

[tomas-langer]

Codegen is currently (successfully) used across Helidon, though we discovered a few things that may require redesign/improvement.

A few steps needed for this to be feasible

1. Codegen should be marked as Internal API, as we need to change it to suit our needs (in 4.x)
2. In the next major release, we keep it as internal and this task should be started so we plan the changes
3. In the major relase after that, we should implement these changes

This task is to gather the requirements, and possibly do partial/bigger redesign

Related topics (all for discussion and analysis):

• TypeInfo does not seem to fit to common-types, it should be either it codegen or codegen-apt

• Builder codegen (any maybe other that require Javadoc to be useful) do not need to be abstracted from annotation processing; it would benefit if we could use APT APIs (such as Trees, DocTree etc.)
  This would require a change in dependency structure, and maybe abandoning full abstraction of the underlying environment - i.e. maybe we could have codegen with hard dependency on APT, and resolve our Maven plugin (and possible other class graph and reflection use cases) without dependency on codegen.

• Class model has public Annotation type, as we have in common-types - we should only use the one from common types (same for Type and TypeName); the Annotation and Type in class-model should be an implementation detail hidden from users, and all APIs should work with common-types (