Fix logic for responds_to? of generic module instances

[HertzDevil]

Fixes #8334 (more specifically snippet 4 there). This resembles #10519 but the mechanisms are vastly different.

There are essentially two kinds of logic used in responds_to?(:foo) filters:

• Non-virtual: If T or its parents define any method called foo, the filtered type is T.
• Virtual: The filtered type is the union of all subtypes of T, through either including or inheriting T, that respond to foo.

Virtual classes and modules are supposed to use the latter, but generic module instances use the former for some reason. This PR makes them behave like non-generic modules:

module A(T)
end

class B(T)
  include A(T)

  def f; end
end

typeof(begin
  x = B(Int32).new.as(A(Int32))
  x.responds_to?(:f) ? x : raise ""
end)      # => B(Int32)
# before: # => NoReturn

One consequence is that even if the generic module itself defines that method, responds_to? will filter the variable to all including types of the module:

module A(T)
  def f; end
end

class B(T)
  include A(T)
end

class C
  include A(Int32)
end

typeof(begin
  x = B(Int32).new.as(A(Int32))
  x.responds_to?(:f) ? x : raise ""
end)      # => B(Int32) | C
# before: # => A(Int32)

This behaviour is currently consistent with non-generic modules. There might be a follow-up PR to make modules exhibit both non-virtual logic and fall back to virtual logic, which can eliminate very large unions and/or NoReturn in some places. (In fact I said the exact same thing on #10519.)

Type filtering and codegen are both backed by Crystal::Type#filter_by_responds_to so this PR fixes both at once.

[asterite]

Thank you!

[sdogruyol]

Thank you @HertzDevil 🙏