Plugin exports access from frontend

[jonah-iden]

What it does

This adds a new service to the frontend which would allow theia extensions to access the exportet api of vscode extensions (or theia plugins) from the frontend.
Frontend because there we have a directly associated plugin host to the current session. If i remember correctly the theia backend is kind of stateless so a user would first have to select a plugin host and that would probably get alot more complicated

There are still some limitations.

• fields are only resolved when retrieving the exports. So when export fields content change the object is not updated.
• Passing functions as arguments when calling a function is currently not supported. So only serializable values work.

How to test

I adde a test command (Plugin API Access Test) which i will remove again before this is merged.
This logs some test calls to the python vscode extension api to the console
Maybe i should rather create a test though.

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

@jonah-iden this is an architectural change that would ample justification. What problem is this solving? If it's a new feature, can we have a feature request, please?

[jonah-iden]

@tsmaeder this would greatly improve the ability for adoptors to use theia- and vscode-extensions together. Previously a theia extension was bound to only be able to use functionality from vscode extensions through published commands. But alot of extensions have alot more functionality which in vscode is no problem, since that can only be extended by other vscode extensions. But for theia we have theia extensions where the only way to access this api is to create another vscode extension which publishes commands which would then call the api of the other extension. This increases project complexity by alot.
We have at least one customer who would benefit alot from this by being able to use functionality from the python and jupyter extension which is not available through commands. Also i can think of two more customers who have features planned that could benifit from something like this.
Previously
This feature is really hard if not impossible to implement from a theia-extension (at least i don't know how to extend the plugin host<->frontend communication from an extension) so having it directly in theia would be much better.

Also could you maybe explain how this is a large architectural change? I just see this as a little optional service which does not disrupt anything? I guess there could be a little security concern. But that could maybe be mitigated by adding a whitelist that an ad

[tsmaeder]

Also could you maybe explain how this is a large architectural change

Just off the top of my head: VS Code is capable of unloading plugins because they can track any references to stuff in plugins. If any random Theia extension can reference stuff in plugins, we can't ever implement that. Right now plugins are isolated and the connections to stuff in plugins is under control of the framework.

[jonah-iden]

@tsmaeder Ah ok i didn't know about the unloading. Thank you for explaining.
Currently though this only features accessing fields and calling functions with serializable data and getting the serializable result back. So there are no actual dependencies on the vscode-extension. The adoptor is the one who would have to ensure the extension is activated and useable.
Even if there would be listeners those would be tracked by the PluginApiAccessExtImpl so this would be a tiny extra step for checking if a plugin could be unloaded. To me it seems all dependencies will still stay under control of the plugin host