Fallback to guessing the active workspace if none is found based on URI

[vinistock]

Motivation

Closes Shopify/ruby-lsp#1689

I believe I understand the problem some users are having. In #950, we changed the logic to not try to guess the active workspace anymore and just rely on the folder passed by VS Code itself.

However, I think this doesn't work for monorepos that place their launch.json configurations on the top level. This project structure:

monorepo/
  .vscode/launch.json
  client/
  server/

For this scenario, even with the multi-root workspace configuration, VS Code gives us the URI for the top level when launching the debugger because that's where the debugging task is configured. But since that's not a Ruby workspace, we never find anything.

If we fallback to guessing the active workspace, we should be able to account for this scenario better.

Implementation

Created a new method to resolve the workspace that accepts a nilable URI. The key difference in behaviour is that if the URI is present, but we can't find a workspace for it, we now fallback to trying to figure out the active workspace (which we weren't doing).

[vinistock]

Apologies for adding more things after approval, but I noticed that we could still improve the spawning of the debugger to be less dependent on the workspace.

I tested the latest commit with a single and a multi workspace configuration and everything seemed to work properly.

[st0012]

Should we error out when the workspace name is unknown? Is it possible to enter this case but still can use the debugger correctly 🤔

[vinistock]

That's a good point. I started saving our resolved workspace in the debug session configuration instead, so that we can reuse it when spawning the debugger.

That way, the error handling happens when resolving debug configurations and spawning just uses the information saved directly.

[st0012]

👍