[Index] Fix missing constructor reference for Self.NestedType() calls

[ileitch]

Constructors called via Self.NestedType() weren't being indexed because the AST uses DotSyntaxCallExpr (not ConstructorRefCallExpr), causing the implicit DeclRefExpr to the constructor to be skipped.

Fix by:

1. Not skipping implicit constructor DeclRefExpr when CtorRefs is empty (i.e., when not already handled by ConstructorRefCallExpr)
2. Unwrapping AutoClosureExpr/CallExpr in isBeingCalled() to correctly detect the call context and add the Call role

[slavapestov]

It's a bug that these calls are wrapped in an autoclosure. We can land this as a workaround, but do you want to investigate and fix the underlying issue?

[slavapestov]

Perhaps the problem is somewhere in shouldBuildCurryThunk() in CSApply.cpp. It has this weird bit of code in it which suggests something is not being modeled properly with constructors:

        // FIXME: Representational gunk because "T(...)" is really
        // "T.init(...)" -- pretend it has two argument lists like
        // a real '.' call.
        if (isa<ConstructorDecl>(member) &&
            isa<CallExpr>(prev) &&
            isa<TypeExpr>(cast<CallExpr>(prev)->getFn())) {
          assert(maxArgCount == 2);
          return 2;
        }

Or maybe the problem is even further upstream. Really, Self.NestedType should be identical to Container.NestedType, because the special meaning of Self inside a class type should not have any effect for a nested type reference.

Nice discovery, by the way, this is really bizarre.

[slavapestov]

I looked into this and there are two issues:

• We don't fold Self.NestedType in the same way as Container.NestedType
• We form an autoclosure erroneously in other cases

I have a fix for the first problem coming up, which eliminates the autoclosure. I'll see if I can fix the second as well.

[slavapestov]

Here is the fix for the underlying problem: #86146