Propagate clang module in SwiftInfo for objc-only frameworks

[jschear]

TL;DR: the SwiftInfo provider returned by the apple_framework_packaging rule should define a clang_module for the framework (even if the framework only contains objective-C code).

Background

When attempting to upgrade our repo from rules_swift 1.18.0 to 2.3.1, building some swift_library targets that depend on an ios_framework_packaging target was failing:

~/Development/ios-register js/rules_swift_2 bazel build //Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public:BBFrontendCardAssignmentCandidateParsing --disk_cache= --remote_cache=              
INFO: Analyzed target //Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public:BBFrontendCardAssignmentCandidateParsing (55 packages loaded, 1107 targets configured).
ERROR: /Users/jschear/Development/ios-register/Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public/BUILD.bazel:8:19: Compiling Swift module //Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public:BBFrontendCardAssignmentCandidateParsing_swift failed: (Exit 1): worker failed: error executing SwiftCompile command (from target //Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public:BBFrontendCardAssignmentCandidateParsing_swift) 
  (cd /private/var/tmp/_bazel_jschear/acffefc2aaf2db6ab6b8a66840ea95d7/execroot/register && \
  exec env - \
    APPLE_SDK_PLATFORM=iPhoneSimulator \
    APPLE_SDK_VERSION_OVERRIDE=18.1 \
    PATH=/bin:/usr/bin:/usr/local/bin \
    XCODE_VERSION_OVERRIDE=16.1.0.16B40 \
  bazel-out/darwin_arm64-opt-exec-ST-a828a81199fe/bin/external/build_bazel_rules_swift/tools/worker/worker swiftc @bazel-out/ios_sim_arm64-dbg-ios-sim_arm64-min15.0-applebin_ios-ST-b326c92d7d24/bin/Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public/BBFrontendCardAssignmentCandidateParsing_swift.indexstore-0.params)
# Configuration: cfd025cb943dcdd01a7b20e1f527617a5e1f7ed427460210ceea3445db0a2c6a
# Execution platform: @@internal_platforms_do_not_use//host:host
Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public/Sources/CardAssignmentCandidate+Protos.swift:3:8: error: no such module 'squareup_bbfrontend_service_v1_additional_card_proto_objc'
  1 | import BBFrontendCardAssignmentCandidate
  2 | import BBFrontendCore
  3 | import squareup_bbfrontend_service_v1_additional_card_proto_objc
    |        `- error: no such module 'squareup_bbfrontend_service_v1_additional_card_proto_objc'
  4 | 
  5 | // MARK: - Encoding
Target //Frameworks/BBFrontendCore/Frameworks/BBFrontendCardAssignmentCandidateParsing/Public:BBFrontendCardAssignmentCandidateParsing failed to build
INFO: Elapsed time: 2.718s, Critical Path: 1.44s
INFO: 7 processes: 3 internal, 4 local.
ERROR: Build did NOT complete successfully

Using aquery and comparing rules_swift 1.18.0 to 2.3.1, I discovered that the modulemap and headers for the framework were previously added to the swift compilation actions via the CcInfo provider's compilation_context.headers field: https://github.com/bazelbuild/rules_swift/blob/1.18.0/swift/internal/compiling.bzl#L1547-L1568

In rules_swift 2.x+, that codepath has changed: the CcInfo is only used for explicit clang module builds, and the headers and modulemap from targets we depend on are instead gathered from the module field of the SwiftInfo provider for each dependency.

For an objc_library, the "module" would normally be created by the swift_clang_module_aspect. But that aspect doesn't know about our apple_framework_packaging rule, and we already expose a SwiftInfo provider, so we should add the clang module to it.