Fix type restriction logic for generic module instances

[HertzDevil]

Revival of #5132. Fixes #4287. Fixes #4684. Does not affect #9660.

typeof(begin
  x = uninitialized Enumerable(Int64)
  x.is_a?(Indexable(Int64)) ? x : raise ""
end) # => (StaticArray(Int64, 3) | Tuple(Int64, Int64))

The union above is essentially all including types of Indexable(Int64) in the standard library defined prior to this typeof. This is not ideal because if the other type implements the current type then we could simply return Indexable(Int64) here (see also #2404 (comment)), but this behaviour is consistent with non-generic module instances:

module A; end
module B; include A; end
class C; include B; end
class D; include B; end

typeof(begin
  x = uninitialized A
  x.is_a?(B) ? x : raise ""
end) # => (C | D)

The reason that previous PR fails seems to be that without the type restriction in Crystal::GenericModuleInstanceType#restrict it catches all AST node restrictions too, and leads to an infinite recursion inside GenericInstanceType#restrict(other : Generic, context). From my own experience it happened between Comparable and Pointer in the prelude:

• Comparable(Array(T)) v.s. Pointer(T)
• (Array(Array(Crystal::DWARF::LineNumbers::Row)) | Array(Array(PrettyPrint::Group)) | ...) v.s. Pointer(T)
• Array(Array(Crystal::DWARF::LineNumbers::Row)) v.s. Pointer(T)
• Comparable(Array(T)) v.s. Pointer(T)
• ...

[asterite]

I put a ❤️ in the issue, but here are some more:

❤️ ❤️ ❤️ ❤️ ❤️

[HertzDevil]

The stack overflow is back if this is rebased on top of #10522. I'll need to rethink about this... (that PR could go ahead first)

My hypothesis is that code that does:

y = restrict(x, other)
return ... unless y
# y isn't used afterwards

can be replaced with restriction_of?. Then the infinite recursion will probably go away (it happens between parents and including_types). We can't use implements? because non-strict matching is still here.

Should be fixed now.

[asterite]

Great!