Allow more requests to be extended

[vinistock]

In #782, we encapsulated the logic to execute multiple listeners in the base implementations. Let's generalize this even more to be implemented in the parent Listener class and let's expose a configuration to allow requests to be extended.

Something like this

class Hover < Listener
  extensible!
end

Then let's allow the following requests to be enhanced by extensions:

• semantic highlighting
• document symbols - Make document symbol extensible #949
• definition - Make Definition extensible #989

[st0012]

Today at the DX stream meeting we talked about that on some requests, we may need to expose more info or even make certain data mutable to our extensions. I think semantic highlight may be one of them.

Consider this:

class Foo < ApplicationRecord
  before_save :bar
end

Currently before_save is marked as a method with no modifiers by ruby-lsp. If ruby-lsp-rails wants to enhance it by assigning modifiers (e.g. declaration), the current way of merging response won't be able to achieve it.

@vinistock can you check if my understanding on this case is correct. And if it is, should we still make it extensible before we discuss further about the data flow between ruby-lsp/extensions?

[vinistock]

Yes, your understanding is correct. We'll indeed need to think of a better strategy if two extensions want to modify the same semantic token. Let's put this on pause while we plan of a better abstraction for merging responses from extensions.

[st0012]

Waiting for https://github.com/Shopify/ruby-dev-exp-issues/issues/1050

[st0012]

I think this has been completed as the response building mechanism has been completely redesigned and individual requests can decide how their responses should be exposed to addons pretty easily.