Remove lens.forceCustomCommands config

[Veykril]

          > Is there any impact of this other than an unnecessary round trip? I'm trying to understand what the error / problem is here, but I'm not seeing it.

That depends on the client, we are violating the LSP (or in this case the lsp extension I suppose), we shouldn't be doing that.

The problem is this config being enabled by default for some reason https://github.com/veykril/rust-analyzer/blob/09ef75c717e9ffb4cbc71ce1cfec7694244742c2/crates/rust-analyzer/src/config.rs#L564 which then force enables all of the commands here https://github.com/veykril/rust-analyzer/blob/09ef75c717e9ffb4cbc71ce1cfec7694244742c2/crates/rust-analyzer/src/config.rs#L1896-L1911
We should just get rid of lens_forceCustomCommands, I see no value in it for debugging.

Originally posted by @Veykril in #17587 (comment)

[joshka]

For context, the original reason for this setting being set to true is documented in Veykril@be84f85#diff-779cb31c0defa0631d570725eb4ca124c0860d6ec07bb5b9deddc2dd34966315 in July 2021:

feat: gate custom clint-side commands behind capabilities

Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.

Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.

That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via extensions
field of the ClientCapabilities.

To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.

So, if you maintain a rust-analyzer client and implement
rust-analyzer/runSingle and such, please also advertise this via a
capability.

[PaulDotSH]

@rustbot claim