Test explicit modules with Swift 6.4

Currently with Swift 6.3, unless you pass `--features=swift.use_explicit_swift_module_map`, Swift doesn't record the _path_ to transitive swiftmodule dependencies in your output swiftmodule. For example:

```bzl
swift_library(
name = "lib",
srcs = ["lib.swift"],
module_name = "lib",
)

swift_binary(
name = "bin",
srcs = ["bin.swift"],
deps = [":lib"],
)
```

```
$ llvm-bcanalyzer --dump bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule | grep IMPORTED_MODULE
blob data = 'Swift'
blob data = 'SwiftOnoneSupport'
blob data = 'Testing'
blob data = '_Concurrency'
blob data = '_StringProcessing'
blob data = '_SwiftConcurrencyShims'
blob data = 'lib'
```

This potentially matters for debugging. First party dependencies, like my `lib` in this example, get added to the final binary with `-add_ast_path`, so those aren't a problem:

```
$ dsymutil -s bazel-bin/examples/bin | grep AST
[ 20] 000006a7 32 (N_AST ) 00 0000 0000000000000000 'bazel-out/darwin_arm64-dbg/bin/examples/lib.swiftmodule'
[ 21] 000006df 32 (N_AST ) 00 0000 0000000000000000 'bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule'
```

But for dependencies like `Testing` here, which is a swiftmodule that was built from a swiftinterface in the SDK (vs Swift and some of the other modules which are provided as prebuilt swiftmodule files), it's possible lldb cannot find this swiftmodule and that degrades debugging. It looks to me like it will still find the prebuilt swiftmodule file ones, so we don't have to worry about those.

When you pass `--features=swift.use_explicit_swift_module_map`, the relative paths from the explicit module json file are also stored here:

```
$ llvm-bcanalyzer --dump bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule | grep IMPORTED_MODULE
blob data = 'Swift'
blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/Swift.swiftmodule/arm64e-apple-macos.swiftmodule'
blob data = 'SwiftOnoneSupport'
blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/SwiftOnoneSupport.swiftmodule/arm64e-apple-macos.swiftmodule'
blob data = 'Testing'
blob data = 'bazel-out/darwin_arm64-dbg-ST-52388a551d5e/bin/external/+system_sdk+system_sdk_xcode_26_4_1_17E202/MacOSX_Testing_outs/Testing.swiftmodule'
blob data = '_Concurrency'
blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/_Concurrency.swiftmodule/arm64e-apple-macos.swiftmodule'
blob data = '_StringProcessing'
blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/_StringProcessing.swiftmodule/arm64e-apple-macos.swiftmodule'
blob data = '_SwiftConcurrencyShims'
blob data = 'lib'
blob data = 'bazel-out/darwin_arm64-dbg/bin/examples/lib.swiftmodule'
```

Currently these paths would have to be remapped separately, but we might be able to change `__bazel_developer_dir_26_4_1_17E202` to `PLACEHOLDER_DEVELOPER_DIR` so that only one lldb mapping has to be added by the user.

Swift 6.4 will have this commit: https://github.com/swiftlang/swift/commit/fa71d1da59594522716ab7304d8049369deac5c3 which makes it look like it will store the path to the explicit module json file itself, which will change things a bit. We'll have to test with that version to see how it works once an Xcode beta is available with it.

Reproduce the example with Swift 6.4 once an Xcode beta is available, using the explicit module JSON and the llvm-bcanalyzer and dsymutil commands shown in the issue. Compare the recorded paths and LLDB behavior with and without swift.use_explicit_swift_module_map; done means documenting the resulting path-remapping requirements and any needed rules_swift change.

Written by the indexing model from the issue text.