Optionally pass a --storage-directory argument to the LSP server

[nberth]

This change avoids creating a _superbol folder in each project's root directory. A storage space provided by the client is used instead.

For now, the "global" storage space provided by VS Code for the extension is used. It is unclear (/ I did not search for) who is responsible for cleaning that space (or the local storage).

[nberth]

Actually, just found out we don't have a "simple" way of dealing with the cleanup problem by only relying on VS Code (cf microsoft/vscode#32461).

Temporary solution: do not merge this and continue relying on a _superbol sub-folder at the root of the project.

Later: use the extension context's globalState to store an association list of workspace/project directories → cache storage directories, and implement a basic cleanup strategy upon activation/deactivation.

[engboris]

Can you explain why you use ExtensionContext.globalStorageUri instead of ExtensionContext.storageUri? I see you have a comment about it but maybe I'm missing some subtlety.

Do you expect the storage to be accessible from all workspaces?

[nberth]

Can you explain why you use ExtensionContext.globalStorageUri instead of ExtensionContext.storageUri? I see you have a comment about it but maybe I'm missing some subtlety.

Do you expect the storage to be accessible from all workspaces?

Yes. We store a cache on a per-project directory basis, not per-workspace. So, it could be relevant to reload a project from the same cache even if that's from two distinct workspaces (especially if the configurations match, which is likely if projects have a superbol.toml).

However, as I noted in the previous comment, we have no "simple" way of cleaning caches. And apparently, this problem would also arise if we were to use workspace-storage instead.