[NFC] Swap the order of checks in redeclaration checking

An nth order effect of computing isInvalid() is that we can potentially
wind up type checking during redeclaration checking.  This wouldn't
normally be a problem, but under the current validation order it's more
likely that the DeclChecker has already fired before we run
redeclaration checking.

If we move to any other validation order, the request wins.  For
VarDecl, that means the PatternBindingInitializerRequest fires and we
type check with the pattern binding as the decl context.  Under the
previous scheme, we would visit the accessor decl and use that as the
decl context.  Here's the rub: The request case records a cascading
dependency edge while the DeclChecker case records a private edge.  This
means the frontend can wind up emitting two different reference
dependency sets for the same primaries as in

NameBinding/reference-dependencies-consistency.swift

Fix this by sinking the interface type computation after the access
control check which, thankfully, does not depend on the interface type.

Author: CodaFi

lib/Sema/TypeCheckDecl.cpp

@@ -736,10 +736,6 @@ static void checkRedeclaration(ASTContext &ctx, ValueDecl *current) {
     if (!conflicting(currentSig, otherSig))
       continue;
 
-    // Skip invalid declarations.
-    if (other->isInvalid())
-      continue;
-
     // Skip declarations in other files.
     // In practice, this means we will warn on a private declaration that
     // shadows a non-private one, but only in the file where the shadowing
@@ -748,6 +744,10 @@ static void checkRedeclaration(ASTContext &ctx, ValueDecl *current) {
     if (!other->isAccessibleFrom(currentDC))
       continue;
 
+    // Skip invalid declarations.
+    if (other->isInvalid())
+      continue;
+
     // Thwart attempts to override the same declaration more than once.
     const auto *currentOverride = current->getOverriddenDecl();
     const auto *otherOverride = other->getOverriddenDecl();