Symmetric common_descendent for two generic class types (#10831)

[stakach]

Fixes #10831.

The bug

class A; end
class B(T) < A; end
class C(T) < B(T); end

x = C(Int32).new.as(A)
x.is_a?(B) && x.is_a?(C)   # => false   (should be true)

After the first is_a?(B) narrows x to B(T), the chained is_a?(C) is supposed to narrow further to C(T) — every runtime C is also a B. Instead it evaluates to false even though the runtime value really is a C.

Root cause

Type::common_descendent(GenericClassType, GenericClassType) only walked the relationship in one direction:

def self.common_descendent(type1 : GenericClassType, type2 : GenericClassType)
  return type1 if type1 == type2

  common_descendent_instance_and_generic(type1, type2)
end

common_descendent_instance_and_generic(B, C) asks "is there a path from B's parents down to C?" — and there isn't (B is the parent, C is the child). The intersection collapses, the filter narrows to nothing, and is_a?(C) returns false.

Fix

Try both directions, so the relationship between two generic class types flows whichever way the chain happens to be written:

common_descendent_instance_and_generic(type1, type2) ||
  common_descendent_instance_and_generic(type2, type1)

The symmetric form mirrors the pattern already used for VirtualType, VirtualType (line 170) and for the class C(T) < B(T) family of relationships specifically.

Tests

• spec/compiler/semantic/is_a_spec.cr — run(...).to_b regression for is_a?(T) can break further type filtering if T is an uninstantiated generic #10831. Verified to evaluate to false on master and true here.

Note

This was originally part of #16982 along with #11134's virtual metaclass dispatch fix. Per review feedback, they're being split into separate PRs — they're related symptoms but fix different code paths and warrant independent review.