Improve the current generator types

[Tcharl]

Overview of the feature request

The goal would be to handle the generator types and host them in their relative owner generators compared to the current situation were all (most) of the types are referenced within a central point.

To schematize the current types to generator relationships in a small sample:

Here, we can notice some drawbacks/surprises for newcomer, and here are the ones that I identified:

• Any other generator (i.e. generator/server, other Client generators like react, any blueprint) are using a type that is extending AngularApplication so every generators will have autocomplete on the attributes of this type even the ones that doesn't need it.
• Also this inheritance chain seems counterintuitive (I always learned at school that 'Circle' extends 'Shape', not the reverse)
• It also creates tight coupling and forces the generators to be released as a big monolith (e.g. if an attribute of CypressApplication is modified, generators/angular should also be released because we cannot guess easily the impact of such a change on the other generators.
• Finally, blueprints, even backend ones are forced to extend generator/client which seems confusing

Proposed solution

At target, the object inheritance could be improved following this approach

This type architecture will come with multiple advantages:
. IDE will autocomplete only fields needed: for example, autocomplete and type of field of AngularApplication won't be available on generator/server
. releases of generators can be modularized, i.e. generator/angular can be released only when generator/angular, generator/client or generator/base have been modified, but it won't be necessary to release it when generator/server will be modified
. Blueprints will have to extend leaf generators they need (i.e. generator/angular) lowering the need of synchorinzing with the upstream
. SOLID principle and clear separation of concern at all levels

Transitory solution

As this would be a breaking change for blueprint, I propose to first move objects in their respective generators first, then modify the inheritance chain for V9 (or V10 if we follow deprecation cycles).

Partial<Generator><Application|Entity> will be deprecated because they keep being extended by abstraction generators, which is not the objective (i.e. at target, we should allow a dependency from generator/angularto generator/client but not the reverse)

At least at transitional step, the generator will use the right object in its generics, and same for the generics of entity (i.e. AngularGenerator<AngularEntity<AngularField>> And the types will be located on the right generator.
it will then be very easy to move all the fields/methods of the partial object to their non-partial counterpart of the next (or next-next) version.

Motivation for or Use Case

• Releasing generators independently
• Locating objects on their own generators
• Respecting SOLID principles
• Modularizing jhipster core: some would just want to consume application generators, others platforms generators, some other only entities, others just extending servers, etc.

Related issues or PR

• Checking this box is mandatory (this is just to show you read everything)