explorer: initial actions to commands transition

[isidorn]

fixes #24900

1. All actions need to be transitioned into commands. Some of these commands need to get a hold of the active tree which should be done using the listService
2. Context keys need to be managed by the explorer when selection changes in order to show / hide the actions. e.g context key if the selected file is a folder
3. Need to use groups to preserve the sorting of actions

This is work in progress, currently I am simply transitioning a couple of actions into commands.

fyi @bpasero

[bpasero]

@isidorn I would not call this explorer commands for layering reasons (explorer is a contribution to the workbench, and editor is not). Just call them editor commands or similar.

[isidorn]

Make sense, I will change it.

[bpasero]

@isidorn would it not be enough to call editorinput.getResource()? Every editor now has this method so you can get the resource from there.

[isidorn]

@bpasero notice that in some actions I only have a resource and then I have to pass them on to the command somehow without having the editor.
Currently I do
return this.commandService.executeCommand(OPEN_TO_SIDE_COMMAND_ID, { resource: this.resource });

An ugly alternative is
return this.commandService.executeCommand(OPEN_TO_SIDE_COMMAND_ID, { editor: { getResource: () => this.resource }});

[bpasero]

@isidorn feedback as discussed:

• Fix broken tests
• autoSaveNotAfterDelayContext => config.autoSave (if possible) with the configured value
• explorer should set the folder context if in single-folder mode and not having anything selected to get those commands to show up when right clicking into empty space
• get rid of actions that have duplicate IDs as commands and use menu service to contribute to quick open (verify via the "Close" action when closing a tab)
• "open in terminal" fails when doing on files (seems to try to open the file in the terminal and not its parent)
• introduce a new context to enable "Compare with chosen" conditionally
• "Add folder to workspace" command seems to fail
• "Open folder settings" command seems to fail
• Actions that we contribute from built in extensions should adopt our groups (e.g. "Open in Preview" for markdown)
• Release Notes: our context menu groups in the explorer so that extensions can pick it up properly

Debt to think about: currently we seem to register commands not from *.contributions.ts but from other places. One alternative solution would be to only define the command handler and then do the registration all from the *.contribution.ts files. That also avoids having to pass around command IDs.

[isidorn]

@bpasero I checked and the Open Preview in makrdown is the only built in extension which contributes. But look at my commit it shows that people were expecting navigation here even before we actually introduced it to the explroer.

So it would be nice to have the same name, however not sure how then to fix the ordering problem.

[bpasero]

@isidorn we could maybe bring back that group and a) for the open editors make it the primary group and b) for the explorer make it the secondary one so that the group for "New" wins over it.

[isidorn]

fyi @bpasero I am wrapping this up and will probably merge into master later today / tomorrow morning

There are still some minor issues but I will treat them as bugs and fix as we go.

[isidorn]

I have merged in this PR, I have created #40909 and #40910 as follow up items. Could not fix the terminal issue since the terminal is not working on my out of source due to unrelated reasons.
Once you try it out just ping me with issues you see or just file issues (whatever suits you better)
As for release notes I propose to do that in the endgame week.