Clarify semver stable api for blueprints.

[mshima]

Overview of the feature request

generators/*/support/* should be stable for blueprints usage.
Those apis are exported and should follow semver.

generator-jhipster/package.json

Lines 64 to 67 in 14191e8

	"./generators/*/support": {
	"types": "./dist/generators/*/support/index.d.ts",
	"default": "./dist/generators/*/support/index.js"
	},

generator-jhipster/package.json

Lines 72 to 75 in 14191e8

	"./generators/*/generators/*/support": {
	"types": "./dist/generators/*/generators/*/support/index.d.ts",
	"default": "./dist/generators/*/generators/*/support/index.js"
	},

Motivation for or Use Case

Related issues or PR

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

[Tcharl]

I would prefer to have types owned by their respective generators before thinking about fixing another api (#28235).
Doing so would permit blueprints to stick with the semver of their respective generators.

We can speed up the process by focusing on coarse grained semver then going more and more fined grained
Let's imagine a semver like this for a server blueprint (i.e. jhipster-spring-cloud-rabbitmq, or jhipster-quarkus):

• Jhipster 'core' (e.g. generator-base-*) is in version 9. Its semver second bit can only be an internal api change.
• Jhipster 'server' (i.e. generator-server) is in version 9.2 (the first bit being the one of the core). the second bit is the amount of breaking changes of the -server flavour.
• Jhipster 'quarkus' can then use the third bit for their releases.

Other suggestion: the second bit could be a sequence of numbers ABCD where each number would be the 'api with breaking change' version of each intermediate generator between the base one and the leaf blueprint

'till we get a real @jhipster/server/blueprint npm package layout, it could be a trick to get something. But it needs to decouple server vs client vs platform (including their types) first.