Generates devfile v2 entries in addition to meta.yaml entries generated from che-editors/che-plugins yaml files

[benoitf]

Is your task related to a problem? Please describe.

plugin-broker is consuming for now meta.yaml from the plug-in registry.
With devfile 2, consumers won't be able to consume 'meta.yaml' format.
As we have a central/pivot format, we can generate both meta.yaml and devfile v2 entries

Describe the solution you'd like

generate devfile entries from che-editors.yaml and che-plugins.yaml files

Describe alternatives you've considered

step2: could convert the che-editors.yaml and che-plugins.yaml to be devfile 2.0 objects (and still generate meta.yaml/devfile.yaml)

Additional context

There is some limitation on devfile 2.0 consumer like dev workspace operator, s:

1. it shouldn't generate entries with secure/true
2. 127.0.0.1 listening is not supported so it should be mapped to 0.0.0.0

cc @sleshchenko please provide any input about current limitations that I've not listed

[sleshchenko]

If I'm not mistaken, currently Che Plugin Broker overrides plugins entrypoint to use remote-runtime binary, with devworkspace and devfile, that's plugin registry who should provision that stuff into plugin's definition.

^ Seems I'm wrong and sidecar defines entrypoints and expects PLUGIN_REMOTE_ENDPOINT_EXECUTABLE env var to be injected https://github.com/eclipse/che-plugin-registry/blob/master/sidecars/java/Dockerfile#L32
but devWorkspace is not going to set this value. So, plugin registry should care about it, or somebody else on the workspace start chain

[benoitf]

@sleshchenko good question/feedback. Will need to think on who will set that variable. Probably che-theia that will take care of plug-ins as value is defined in che theia current meta.yaml definition

But management of theia plug-ins is for milestone 2 (so still some time to think about it)