Add option to enable/disable .cabal file support

[fendor]

Support for .cabal files was implemented in HLS 2.0.0.0. But the vscode-haskell extension does not enable this Language Server support, because it would break for older HLS binaries, as these were unable to handle file updates for .cabal files.
To work-around, we had a pre-release of the vscode-haskell plugin, which enabled support for .cabal plugins in an opt-in fashion.

It's been a while, and we want to enable language server support for .cabal files unconditionally. There are still HLS binaries around that can't handle .cabal files, but it much less.
For the unfortunate souls left behind with GHC versions such as 8.6.5, we add a new vscode-haskell option:

haskell.supportCabalFiles

This option is true by default, but if set to false it will unconditionally disable sending File Notifications for .cabal files, which allows us to keep working for older HLS binaries.

This change would be difficult to test, and incur an, in my opinion, unreasonable price on our CI times.
I manually tested the changes, by using HLS 1.8.0.0 (last released binary for GHC 8.6.5) on a project with haskell.supportCabalFiles set to true and false respectively.
HLS seemed to behave correctly, showing Diagnostics for Haskell files, but not show any logs for .cabal files.
The only potential change in behaviour is that vscode-haskell now also acitvates when a .cabal file has been opened. This may be overly eager to some, but since no Haskell files are typechecked, the impact on memory usage is negligible in my opinion.

[fendor]

@hasufell This is just an FYI for you that we are going to enable Language Server support for .cabal files by default, but there is an option to disable it: "haskell.supportCabalFiles": false

[hasufell]

Can't the extension detect whether the server supports this? LSP can give that information afaik.

[fendor]

This happens before the LSP client is started. We create the LSP client, and we need to specify for which file types we want to receive didChange notifications.
AFAICT, the LSP protocol doesn't have built-in support for changing the set of supported languages, since we arguably should have a separate Language Server for each "language", i.e. one for .cabal and one for .hs files.

We could probably hack something together using custom requests and notifications, but it would not solve the issue, as we would still have to wait a very long time before all older HLS versions that do not come with this hack are phased out.

Another possible workaround is to base the decision of the language support on the HLS binary version, as we know when the hls-cabal-plugin was added and which HLS version can actually handle .cabal files gracefully.
While this would work, this is only relevant for users of HLS 1.8.0.0 (last version supporting GHC 8.6.5). I started on implementing this check, but got carried away in refactorings, so this workaround is still in the making and will take more time.

[hasufell]

Then can't we simply do a check against hls --numeric-version and have 3 values for the option:

• enable
• disable
• automatic (default)

[fendor]

Done. I feel like this is a bit overkill for the amount of users, but here we are now.