Serialize bridging headers into the merged module file.

We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.

There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.

<rdar://problem/17688408>

Swift SVN r20128

lib/Frontend/CompilerInvocation.cpp

@@ -521,8 +521,11 @@ static bool ParseFrontendArgs(FrontendOptions &Opts, ArgList &Args,
   Opts.SILSerializeAll |= Args.hasArg(OPT_sil_serialize_all);
   Opts.ImportUnderlyingModule |= Args.hasArg(OPT_import_underlying_module);
 
-  if (const Arg *A = Args.getLastArg(OPT_import_objc_header))
+  if (const Arg *A = Args.getLastArg(OPT_import_objc_header)) {
     Opts.ImplicitObjCHeaderPath = A->getValue();
+    Opts.SerializeBridgingHeader |=
+      !Opts.PrimaryInput && !Opts.ModuleOutputPath.empty();
+  }
 
   for (const Arg *A : make_range(Args.filtered_begin(OPT_Xllvm),
                                  Args.filtered_end())) {