Compiler: fix abstract def check regarding generic ancestor lookup

[asterite]

Fixes #8096

Thank you @exilor ! Thanks to your bug report I was able to understand why other (rare) cases were failing too.

The code is this:

module ICallable(T)
  abstract def call(foo : Proc(T))
end

module Caller
  extend self
  extend ICallable(Nil)

  def call(foo : Proc(Nil))
  end
end

And the compiler will check that ICallable(T)#call is implemented by all concrete subtype. One such subtype is Caller:Module (where class methods live). Does it provide a call method? No. Then the compiler goes and check whether any ancestor of Caller:Module provides it. Because it extends self it checks whether Caller (where instance methods live) provides it. And it does! But we must check whether that matches the method in the generic type. For that the compiler will try to find the generic instantiation of that module. That is, because we are checking a subtype of ICallable(T) then at some point there must have been some include ICallable(X) in the chain, to know what type X is. The problem was that the compiler would start the search from the current ancestor, in this case Caller, and not from the main type we were checking in the first place (Caller:Module).

It's a bit confusing. That's why I also added a similar spec which is a bit simpler:

module ICallable(T)
  abstract def call(foo : T)
end

module Moo
  def call(foo : Int32)
  end
end

module Caller
  extend ICallable(Int32)
  extend Moo
end

Here the compiler again will check whether Caller:Module implements call. It will find that Moo has it and then it will try to find the include/extend ICallable, but it won't find starting from Moo, it will find it starting from Caller:Module. Well, at least in this case, in other cases it might happen that Moo is the one that is including the other module.

[asterite]

Also undoes #8035 because this fix is the right solution to the problem, the other one was not.

[asterite]

@RX14 Thanks! 🙏