[ParseableInterface] Fix failing to build a module when the importing file has errors.

We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.

This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.

rdar://problem/43906499

test/ParseableInterface/ModuleCache/module-cache-errors-in-importing-file.swift

@@ -0,0 +1,23 @@
+// RUN: %empty-directory(%t)
+// RUN: %empty-directory(%t/modulecache)
+//
+// Setup builds a parseable interface for a module SomeModule (built from some-module.swift).
+// This test checks we still build and load its corresponding .swiftmodule when the file that imports it contains an error prior to the import statement.
+
+// Setup phase 1: Write the input file.
+//
+// RUN: echo 'public func SomeFunc() -> Int { return 42; }' >>%t/some-module.swift
+
+// Setup phase 2: build the module.
+//
+// RUN: %target-swift-frontend -I %t -emit-parseable-module-interface-path %t/SomeModule.swiftinterface -module-name SomeModule %t/some-module.swift -emit-module -o /dev/null
+
+// Actual test: compile and verify the import succeeds (i.e. we only report the error in this file)
+//
+// RUN: %target-swift-frontend -typecheck -verify -I %t -module-cache-path %t/modulecache -enable-parseable-module-interface %s
+
+unresolved // expected-error {{use of unresolved identifier 'unresolved'}}
+
+import SomeModule
+
+print(SomeFunc())