Propagate clang module in SwiftInfo for objc-only frameworks (#939)

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](https://github.com/bazelbuild/rules_swift/blob/2.3.1/swift/toolchains/config/compile_config.bzl#L1569-L1584),
and the headers and modulemap from targets we depend on are instead
gathered from the [module field of the SwiftInfo provider for each
dependency](https://github.com/bazelbuild/rules_swift/blob/2.3.1/swift/toolchains/config/compile_config.bzl#L1605-L1616).

For an `objc_library`, the "module" would normally be created by the
[swift_clang_module_aspect](https://github.com/bazelbuild/rules_swift/blob/master/swift/swift_clang_module_aspect.bzl#L778-L782).
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.

Author: jschear

rules/framework.bzl

@@ -598,6 +598,13 @@ def _get_merged_swift_info(ctx, framework_files, transitive_deps, clang_module):
     }
     if framework_files.outputs.swiftmodule:
         swift_info_fields["modules"] = _copy_swiftmodule(ctx, framework_files, clang_module)
+    else:
+        swift_info_fields["modules"] = [
+            swift_common.create_module(
+                name = ctx.attr.framework_name,
+                clang = clang_module,
+            ),
+        ]
 
     return swift_common.create_swift_info(**swift_info_fields)