Client-side editing overhaul

[isc-bsaviano]

• Fixes Support non-isfs virtual workspaces for client-side editing #1278.
• Create an index of all Classes, MAC and INT routines, and Include files inside non-isfs workspace folders:
  • Create two maps: one with the document name as the key and an array of Uris as the value, and one in the reverse direction.
  • Use a FileSystemWatcher to update the index when files are created, deleted or changed on disk and an onDidChangeTextDocument handler to update the index when a file is changed within VS Code.
  • Delete a file on the server if the last Uri for it in a workspace folder was deleted.
  • DocumentContentProvider.getUri() will use the index to determine the Uri for a class or routine in a non-isfs folder. The export settings are now only used for non-classes and routines in folders with the file scheme.
  • WorkspaceSymbolProvider will only return results from classes that are in the client-side folder by using the index to determine all known classes.
• Automatically show and hide the InterSystems Explorer and Projects Explorer views based on the folders in the workspace. InterSystems Explorer is only shown if there is at least one non-isfs(-readonly) workspace folder. Projects Explorer is only shown if there is at least one isfs(-readonly). Both are shown if no workspace folders are open. This formally ties the InterSystems Explorer to client-side editing workflows and Projects Explorer to server-side editing workflows. This replaces the objectscript.showExplorer setting.
• Cache the list of Studio Abstract Document extensions that are supported for each server connection so we can properly import them from client-side folders. Importing abstract documents is now independent of the objectscript.export settings, except for DFI’s which still check the export settings to preserve the path splitting behavior added by Improve client-side DFI workflow #808. Any file within a workspace folder that has a supported abstract document extension will be imported with the last part of the path used as the server name (except for DFI’s that match the export settings).
• Don’t allow creation of an editable server-side folder via the Add Server Namespace to Workspace… command if the current workspace already has a client-side folder in it. This is to prevent the blending of client-side and server-side workflows in a way that can lead to lost changes or overwritten edits.
• Change the default value of the objectscript.explorer.alwaysShowServerCopy setting to true. The InterSystems Explorer should always show the server copy since the local copy can be opened from the files explorer.
• Remove the objectscript.export.noStorage setting. Storage is an integral part of the class definition, and we shouldn’t allow removing it.
• Remove the objectscript.export.dontExportIfNoChanges setting. I don’t think that turning it on adds any benefit to the user.
• Check if the file system is writable before exporting or creating a new file.
• Don’t show server-side source control menu options in the InterSystems Explorer.
• Show MultiValue routines in the InterSystems Explorer.
• Hide .bpl and .dtl documents in the InterSystems Explorer since they can’t be opened or edited.
• Create a single error handling method for consistent error reporting.
• Remove unneeded type definitions.
• Upgrade ancient dev dependencies.

[isc-bsaviano]

@gjsjohnmurray @isc-rsingh I've opened this as a draft since this is a giant PR that needs thorough review. I have a few design questions for you that I'd like to resolve before formally starting the review process and seeking feedback from other users:

1. Should I just remove objectscript.explorer.alwaysShowServerCopy? Keeping the setting gives users who liked the previous behavior a way to retain it, but is that behavior desirable? I can’t think of a good reason why you’d want the InterSystems Explorer to show the local copies other than “that’s the way it is by default”.
2. Should I remove the special DFI folder-splitting on export added by Improve client-side DFI workflow #808? Doing so would be backwards incompatible, and that behavior is almost three years old. However, I doubt anyone is using it and it would make sense to treat all Studio Abstract Documents equally.
3. Should the automatic deletion of local files on the server be guarded by a setting so users can disable it? Maybe objectscript.deleteOnFileDelete, modeled after objectscript.importOnSave?

[isc-bsaviano]

@daimor I'd appreciate your feedback on this as a regular client-side editing user.

[isc-rsingh]

Is this worth publicizing on DC for feedback before merging?

[isc-bsaviano]

@isc-rsingh I've already done so: https://community.intersystems.com/post/do-you-use-client-side-editing-vs-code-if-so-we-want-your-feedback