Properly separate back-end and headless plugins

[tsmaeder]

Feature Description:

Currently, we deploy back end and headless plugins the same way. This can lead to issues like #13638. There are a couple of questions open for me:

1. Can plugins be loaded both as headless and back end plugins? Does that ever make sense?
2. Since plugins can be run both as back end and front end plugins, does it make sense to have two different deployment paths for those?
3. For each plugin, we need to decide where a plugin should be run. For extensions that can live in different places, there needs to be a policy. For FE/BE plugins, the scope of the decision is the front end, for headless plugins, the scope of the decision is the back end process.
4. Currently, we decide based on the "entry point" where a plugins runs. However, this is not optimal: many plugins (i.e. those providing only syntax) may have no entry points, but they could probably run in the front end no problem.

[JonasHelming]

@cdamus @martin-fleck-at

[cdamus]

On item 1 I can say that it is a deliberate decision to let plug-in providers offer headless and backend plug-ins in the same package for convenience and clarity of distribution, installation, and update. I'm working on a project that foresees taking advantage of this single-sourcing of both kinds of plug-ins: headless plug-ins contributing application-specific APIs and backend plugins contributing UI that in part delegates to other plug-ins that contribute extensions on those custom APIs.

On item 4 this is one reason why a plugin can optionally use the "theia-headless" value for the "engine" property, if it otherwise wouldn't provide a headless entry-point script. I'm not sure myself how useful this is as it introduces issues in VSIX packaging, I think.