[clang] [clang][deps] Collect discovered module dependencies' Link Libraries (PR #93588)

[Artem Chikin via cfe-commits]

================
@@ -138,6 +139,14 @@ struct ModuleDeps {
   /// determined that the differences are benign for this compilation.
   std::vector<ModuleID> ClangModuleDeps;
 
+  /// The set of libraries or frameworks to link against when
+  /// an entity from this module is used.
+  llvm::SmallVector<Module::LinkLibrary, 2> LinkLibraries;
+
+  /// Autolinking uses the framework name for linking purposes
+  /// when this is false and the export_as name otherwise.
+  bool UseExportAsModuleLinkName;
----------------
artemcm wrote:

>If the idea is to drop the autolink of the current module, should we rework that so that we remove it from the link libraries of the importer instead?

Yeah, that's the thinking behind adding it here - the scanner is aggregating a set of link libraries for the root importer, and an assumption is made that a module with export_as link name set will be covered by a `LinkLibrary` of one of its dependents. e.g. `SomeKit` depends on `SomeKitCore` and the latter sets `export_as SomeKit`. And the scanner's client may only see `ModuleDeps`, and not this info, so it can use this bit to know to avoid processing its `LinkLibraries`.

>From what I can tell the above scenario matches the circumstance where this bit is set on a `Module` -> when a module with the `export_as` name has already been found. 

Given this, I do not really see a reason to report `LinkLibraries` for such modules at all, what do you think that instead of having this bit here we instead just use it in the scanner to know to avoid populating `LinkLibraries` added here? 

https://github.com/llvm/llvm-project/pull/93588