…y` (#1539)

This allows Swift code in the library to depend on XCTest.

If this was passed in `kwargs`, it gets passed along to the internal
`objc_library` targets:
```
~/Development/rules_swift master $ bazel build //examples/apple/mixed_language:MixedAnswer
ERROR: /Users/jschear/Development/rules_swift/examples/apple/mixed_language/BUILD:5:23: //examples/apple/mixed_language:MixedAnswer_headers: no such attribute 'always_include_developer_search_paths' in 'objc_library' rule
ERROR: /Users/jschear/Development/rules_swift/examples/apple/mixed_language/BUILD:5:23: //examples/apple/mixed_language:MixedAnswer_clang: no such attribute 'always_include_developer_search_paths' in 'objc_library' rule
```
We _could_ alternatively `.pop` it off of `kwargs` before passing to
`objc_library`, but tracking which attributes belong to `swift_library`
vs. `obj_library` and which are shared can get a bit complex.

At Square, we're using a headermap for the Swift generated header, so
that the objective-C half of a module is able to import it using
`#import <Module/Module-Swift.h>`.

This headermap target can't be placed in `deps`, as doing so creates a
dependency cycle.

Here is an example of what the use case looks like:
master...jschear:rules_swift:js/demo_swift_header_imports_in_clang_half

```
header_map(
    name = "swift_headermap",
    module_name = "MixedAnswer",
    propagate_include = False,
    # This relies on us knowing the naming scheme used for internal targets in mixed_language_library, which is not ideal.
    deps = ["MixedAnswer_swift"],
)

mixed_language_library(
    name = "MixedAnswer",
    hdrs = ["MixedAnswer.h"],
    clang_copts = [
        "-I$(execpath :swift_headermap)",
        "-I.",
    ],
    clang_deps = [":swift_headermap"],
    clang_srcs = [
        "MixedAnswer.m",
        "MixedAnswerPrivate.m",
        "MixedAnswerPrivate.h",
    ],
    enable_modules = True,
    module_name = "MixedAnswer",
    swift_srcs = [
        "MixedAnswer.swift",
    ],
    target_compatible_with = ["@platforms//os:macos"],
)
```

…umented (#1547)

Signed-off-by: Brentley Jones <[email protected]>
Co-authored-by: Fabian Meumertzheim <[email protected]>

also bump rules_cc to 0.1.2

only way i could figure to get this to work was to not assist in
standing up neither `protobuf_deps()` nor `rules_cc_dependencies()` in
`swift_extra_dependencies()` – this works around the ordering issue that
breaks transitive dep loading of both rules_python/rules_java and our
stardoc configuration

Similar to #1533 but when using `--strategy=worker`


In rules_swift < 3.x the .swiftsourceinfo files are unconditionally
written to the module path. In rules_swift >= 3.x these same files are
no longer tracked by Bazel unless explicitly requested. When using
non-sandboxed mode, previous builds will contain these files and cause
build failures when Swift tries to use them, in order to work around
this compatibility issue, we check the module path for the presence of
.swiftsourceinfo files and if they are present but not requested, we
remove them.

Testing:

- `bazel clean --expunge`
- `git checkout 2.8.2`
- `bazel build @com_github_apple_swift_argument_parser//...
--strategy=worker,local --worker_sandboxing=false` (pass)
- `git checkout master`
- `bazel build @com_github_apple_swift_argument_parser//...
--strategy=worker,local --worker_sandboxing=false` (failure)
- `git checkout <this-branch>`
- `bazel build @com_github_apple_swift_argument_parser//...
--strategy=worker,local --worker_sandboxing=false` (pass)