fix(cli): support package documentation module imports

Resolves https://github.com/tuist/tuist/issues/6637

DocC builds for generated projects could fail on Swift package targets whose public Objective-C headers import another module from the same package. The Firebase fixture exposed two related gaps:

• FirebaseCoreExtension publicly imports FirebaseCore, but Firebase does not declare that as a target dependency in Package.swift. Firebase documents the requirement in a comment instead: https://github.com/firebase/firebase-ios-sdk/blob/1fc52ab0e172e7c5a961f975a76c2611f4f22852/Package.swift#L213-L225
• Tuist removes MODULEMAP_FILE from generated framework targets to avoid baking non-portable absolute module map paths into products. That remains correct, but DocC’s C ExtractAPI invocation needs dependency framework module maps to be available at the canonical Modules/module.modulemap location.

Source pointers

I checked SwiftPM and swift-build before keeping this shape. The implementation now includes comments pointing at the relevant upstream files.

• SwiftPM does not create missing target dependency edges by scanning public headers. It relies on the package manifest dependency graph.
• SwiftPM propagates custom and generated module maps to direct and indirect clients with -fmodule-map-file: https://github.com/swiftlang/swift-package-manager/blob/ff05594c1267137ed5ee2c0076dfaf78f0289877/Sources/SwiftBuildSupport/PackagePIFProjectBuilder%2BModules.swift#L440-L459
• swift-build wires dependency module maps into the ExtractAPI task from the dependency closure: https://github.com/swiftlang/swift-build/blob/af813e185ed298ea7bdb633047f27d15253cdac7/Sources/SWBTaskConstruction/TaskProducers/OtherTaskProducers/TAPISymbolExtractorTaskProducer.swift#L76-L108
• swift-build passes those dependency module maps to Clang ExtractAPI as -fmodule-map-file=...: https://github.com/swiftlang/swift-build/blob/af813e185ed298ea7bdb633047f27d15253cdac7/Sources/SWBCore/SpecImplementations/Tools/TAPISymbolExtractor.swift#L300-L309 and https://github.com/swiftlang/swift-build/blob/af813e185ed298ea7bdb633047f27d15253cdac7/Sources/SWBCore/SpecImplementations/Tools/TAPISymbolExtractor.swift#L398-L404
• swift-build models framework module maps at the canonical Modules/module.modulemap path: https://github.com/swiftlang/swift-build/blob/af813e185ed298ea7bdb633047f27d15253cdac7/Sources/SWBTaskConstruction/ProductPlanning/ProductPlan.swift#L1197-L1200 and https://github.com/swiftlang/swift-build/blob/af813e185ed298ea7bdb633047f27d15253cdac7/Sources/SWBCore/ClangModuleVerifier/ModuleVerifierModuleMap.swift#L74-L78

So this PR mirrors the upstream module-map behavior for Tuist’s generated Xcode project path, and adds a narrowly scoped Firebase compatibility layer for the manifest gap. The added target dependency is derived only from concrete #import or #include references in public headers, only when the imported module matches a regular target in the same package, only when the dependency is not already declared, and only when adding it would not create a cycle. It does not use product names, effective module names, or @import statements.

The module-map change is also gated to framework targets that already had MODULEMAP_FILE. It preserves the existing sanitization behavior and only adds a dependency-analysis-aware post-build script to copy the known module map to $(TARGET_BUILD_DIR)/$(WRAPPER_NAME)/Modules/module.modulemap.

Validation

• xcodebuild test -workspace Tuist.xcworkspace -scheme Tuist-Workspace -only-testing TuistGeneratorTests/ModuleMapMapperTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" COMPILATION_CACHE_ENABLE_CACHING=NO
• xcodebuild test -workspace Tuist.xcworkspace -scheme Tuist-Workspace -only-testing TuistLoaderTests/PackageInfoMapperTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" COMPILATION_CACHE_ENABLE_CACHING=NO -derivedDataPath /tmp/tuist-loader-test-dd
• xcodebuild build -workspace Tuist.xcworkspace -scheme tuist CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" COMPILATION_CACHE_ENABLE_CACHING=NO
• From examples/xcode/generated_multiplatform_app_with_sdk: /Users/pepicrft/Library/Developer/Xcode/DerivedData/Tuist-avdqkhoscuahapbomflgnybwgdsa/Build/Products/Debug/tuist generate --no-open
• From examples/xcode/generated_multiplatform_app_with_sdk: xcodebuild docbuild -workspace App.xcworkspace -scheme App -destination 'generic/platform=iOS Simulator' CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=""
• After the naming cleanup in this update: xcodebuild test -workspace Tuist.xcworkspace -scheme Tuist-Workspace -only-testing TuistLoaderTests/PackageInfoMapperTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY="" COMPILATION_CACHE_ENABLE_CACHING=NO

I also tested two reduced variants:

• Module-map copy only: still failed with the original FirebaseCore/FIRApp.h missing error because FirebaseCoreExtension had no generated build dependency on FirebaseCore.
• Public-header-derived dependency only: generated the missing build edge, but DocC still failed because ExtractAPI could not discover the dependency framework module map without the canonical Modules/module.modulemap copy.