Run `bundle install` if Gemfile but no `Gemfile.lock`

Description

Reproduction steps

Check out a fresh copy of a repo with Gemfile.lock in .gitignore (rubocop/rubocop for example).

The LSP starting will first show a notice about mulitroot workspaces and after discarding that refuse to start with the following:

Project contains a Gemfile, but no Gemfile.lock. Run bundle install to lock gems and restart the server

Would it make sense to automatically run bundle install for the user in these cases? This would probably require explicit user confirmation, similarly to how VSCode asks about trusted folders. Gems may execute arbitrary commands during installation (I think, especially C extensions during compilation). Perhaps the confirmation of VSCode is already enough, if the extension isn't opting in to trusted mode, https://code.visualstudio.com/docs/editor/workspace-trust. I believe that is the case currently, however looks to be vscode specific and not part of the LSP protocol.

Reproduce the startup failure with a fresh checkout containing a Gemfile but no Gemfile.lock, as described in the issue. Review the Ruby LSP startup path and its VS Code workspace-trust integration; done means defining and implementing a safe confirmation flow for running bundle install, with coverage for the missing-lockfile case.