Allow turning off ERB support through setting

[vinistock]

Motivation

Closes #2282

If the user is working on a project with a dependency that prevents the Ruby LSP server from upgrading, the server will not have ERB support.

Unfortunately, mutating the document selector after the client has already launched doesn't stop it from receiving requests for the removed language IDs. And we have no way of knowing if the server version supports ERB before actually launching. It's a chicken and egg problem.

Implementation

I believe the best we can do is the following (implemented in this PR):

1. After launching the server, we check if there's ERB support. If there is, then the server is up to date and we don't have to do anything
2. Otherwise, we print a warning to output tab (should it be a dialog?) and then we restart the server, passing a new option to turn off ERB support before launch (which then has the desired effect of preventing requests for ERB files)

Concerns

Should we even do this? This means that anyone on old server versions will always need to boot the server twice until they manage to upgrade to newer versions.

[st0012]

should it be a dialog?

Yeah I think it should be dialog

Should we even do this?

If the user still can not upgrade the server after seeing the warning, to revert the erb file behaviour the only alternative would be to downgrade the extension version? If that's the case, then I think restarting the server twice seems more acceptable.

[vinistock]

I really dislike the double-start on launch, so I want to propose that we expose a setting to turn off ERB support as an escape hatch for users that cannot upgrade the server. After a few months, we can get rid of the setting and enable ERB support generally.