Raise VS Code API level to 1.68.1.

[tsmaeder]

What it does

Fixes #12029

Contributed on behalf of STMicroelectronics

How to test

1. Remove the default plugins from ./plugins.
2. Built theia
3. do yarn download:plugins
4. Make sure the downloaded plugins are at elvel 1.68.1
5. Run theia and make sure everything works as usual. A good test case would be developing Theia itself.

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

[paul-marechal]

This new version is consistent with the current tracking of supported VS Code APIs.

[colin-grant-work]

I've come in too late here, but I'd like to add a few cents, nevertheless.

I have misgivings about lifting the default supported API to a level that includes code we know to be stubbed. As an application developer, I would not want users downloading plugins when I don't know how stubbed API is actually being used. Much of the stubbed API is fairly self-contained - Test API, Notebook API - so there's a good chance that those stubs won't interfere with functionality the user is accustomed to, but other pieces are not so isolated. For example, if a plugin switches from the visibleEditors API to a TabGroup-based approach, it will just fail, and the user won't have much an idea why. I don't want to have to debug those cases and support them as users encounter them one by one (issues * users), so I would (and will) just set the compatibility level to whatever I can be reasonably confident is actually supported.

So I wonder whether, with the advent of stubbing, we should introduce different concepts of compatibility. In the context of Open VSX, the lower level - real support - could be used for the default download and the higher level - subbed support - for the 'Install another version command,' so that users can be held responsible for their decision there.

[tsmaeder]

@colin-grant-work stubbing and how to advertise it a very good topic, but not for a comment on a PR: this needs to be raised on the mailing list and maybe in a community call if it's a problem. If this rubs you the wrong way, we should talk about it. In the end, this is about enabling adopters (which your group is), not us looking good in a report.