Abstraction level above workspace service layer

[skabashnyuk]

The goal of this issue is rethinking of how we can simplify different aspects of workspace creation.
For instance, it can be WorkspaceBuilderService that takes as input

1. Production recipe or technology(list are discussable)
2. List of features aka IDE plugins: git, java, github, etc.
3. Some general config like total RAM, etc

As a result, will be running workspace with the current Che6 model.The way how the IDE features would be running are dependent on BuilderService configuration, Workspace service capabilities, infrastructure resources, etc, in other words, it's an implementation detail.

Related epics #6792
#8265

[garagatyi]

Features should be declared in a simplified WorkspaceBuilderService input with the respect to different implementations of features. For example, GitHub integration may be created by different authors and the user should be able to choose which plugin to use. Those plugins may have different lists of features and different bugs. We should not restrict user's ability to choose plugins implementations.
Example of such a choice is VSCode. User just chooses plugins to install into VsCode and VsCode doesn't limit user's choice.

[skabashnyuk]

Idea described here #8265 (comment)