Revert "Restrict RemoteASTTypeBuilder::findModule() to the list of loaded modules."

This reverts commit 30ea6ec.

LLDB is smarter than I expected it to be.  One of the failing tests
"metatype" is very short and does not import any modules
whatsoever. It turns out that swift_runtime->GetMetadataPromise()
creates a RemoteAST with the Scratch AST context. LLDB does not
pre-import any modules for the scratch AST context.

Using the scratch context is actually the behavior we'd want for all
kinds of dynamic type resolution, since we need to handle the
worst-case dynamic type (a tuple of existentials that each originate
from different modules that don't import each other) gracefully.

So what I'm going to try next is revert the RemoteAST change and try
to get the dynamic type resolution in this case to use the scratch AST
context instead of the per-module AST context.

I'm still going to add a flag to RemoteAST to indicate wether
importing other modules should be allowed or not and set that
according to whether this is a module context or the scratch context.

Author: adrian-prantl

lib/RemoteAST/RemoteAST.cpp

@@ -570,13 +570,7 @@ RemoteASTTypeBuilder::createNominalTypeDecl(const Demangle::NodePointer &node) {
 ModuleDecl *RemoteASTTypeBuilder::findModule(const Demangle::NodePointer &node){
   assert(node->getKind() == Demangle::Node::Kind::Module);
   const auto &moduleName = node->getText();
-  // Intentionally using getLoadedModule() instead of getModuleByName() here.
-  // LLDB uses RemoteAST for its per-module SwiftASTContext. Importing external
-  // modules here could permanently damage this context, for example when a
-  // Clang import fails because of missing header search options. To avoid this
-  // situation, restrict RemoteAST's access to only the module's transitive
-  // closure of imports.
-  return Ctx.getLoadedModule(Ctx.getIdentifier(moduleName));
+  return Ctx.getModuleByName(moduleName);
 }
 
 Demangle::NodePointer