Finalize unambiguous priorities api changes.

[mshima]

• change every generator to extend base/index.cjs instead of generator-base-blueprint or generator-base.
  generator-base-blueprint and generator-base are in the inheritance tree, but should be dropped for v8.
• complete unambiguous api changes.
• drop deprecated preparingFields and preparingRelationships priorities
• cleanup a few unused generator-base methods.
• move lib/constants/priorities to near the generator that implements it.

Closes #17132

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[Tcharl]

The EACH term is a bit confusing, it could mean that it will modify EACH Entities ^^.

Removing the EACH looks to be more meaningful (meaning that we are focusing on one specific entity).
Am I wrong with the meaning? If it really means EACH, I would go for PREPARING_ENTITIES.

[mshima]

I think we can rename, but let's do it in another PR.

[Tcharl]

Isn't it worth it to create a base-platform/priorities.cjs (a bunch of application), a base-entity/priorities.cjs and maybe a base-field/priorities.cjs?

[mshima]

Isn't it worth it to create a base-platform/priorities.cjs (a bunch of application).

Yes, I think we should call it base-workspaces.
I will create a feature request.

a base-entity/priorities.cjs and maybe a base-field/priorities.cjs?

I don't think so.
But I think we should implement a base-incremental-application for entity changes like liquibase and maybe entity removal.

[Tcharl]

Some users are complaining that generation is all or nothing. Splitting metamodels (and models) could ease to generate only entities and fields that have been updated

[mshima]

@Tcharl the application, entities, fields and relationships are dependent on each other, it's not possible to create a consistent application without preparing everything.
See #19989.

[Tcharl]

Idem: asConfiguringEntityTaskGroup

[Tcharl]

Reviewed
Please take the comments into consideration:

• Priority names should be crystal clear, the X_EACH_ENTITY is not that clear: we don't know if the processing should be on every entities (in this case X_ENTITIES would be more clear) or if the processing is applied on one specific entity (thus X_ENTITY would be more clear)
• It may be cleaner to split the generator's lifecycle (and metamodel) of platform vs application vs entity vs fields. It would prepare future 'thiner' generators and improve the readability of the model and generator's code

[mshima]

@Tcharl can this PR be merged?
It only reorganizes current implementation, and cleanup some methods.
If we need to change anything we should create a new PR.

[mraible]

I took a brief look and it seems like most phases are suffixed with 'ing', which makes me think they are called at the beginning of a phase. The only one that looks weird is "END", which might make sense if it's called at the very end.