Handle active support concern's recursive nature

This might require some infrastructure changes and new APIs in the Ruby LSP side, but we came to realize that there's one aspect of concerns we are unable to match with the current approach.

If a concern includes another concern which defines class methods, those class methods are recursively extended to all other including concerns. For example:

module ConcernWithClassMethods
  extend ActiveSupport::Concern

  module ClassMethods
    def foo; end
  end
end

module OtherConcern
  extend ActiveSupport::Concern
  include ConcernWithClassMethods
end

OtherConcern.foo # ok!

module YetAnotherConcern
  extend ActiveSupport::Concern
  include OtherConcern
end

YetAnotherConcern.foo # ok!

class Bar
  include YetAnotherConcern
end

Bar.foo # ok!

This is a bit challenging to fix with our current architecture because ancestor linearization is done all lazily for better performance and in this particular example, ancestors of the attached class alter the ancestors of the singleton class.

That is, you need to linearize the ancestors of Bar to discover that Bar::<Class:Bar> inherits from ConcernWithClassMethods::ClassMethods. We may need some way to have concerns mark the namespaces that include them with some flag telling the algorithm that, for those namespaces, you have to first linearize the attached class in order to accurately linearize the singleton class.

Start by reproducing the nested ActiveSupport::Concern example in the issue and tracing the lazy ancestor linearization for Bar and its singleton class. Inspect the concern handling and ancestor-linearization entry points; done means recursively included concerns expose their class methods on the final class without losing the current performance approach.