This is the second in a stack of PRs across three repositories.

- bazelbuild/apple_support#491
- #1623 <-- you are here
- MobileNativeFoundation/rules_xcodeproj#3250

It takes the approach suggested in
MobileNativeFoundation/rules_xcodeproj#1119 and applies it to our swift
toolchain. By breaking sandboxing rules and remapping a derivable path
to the source root, we can to allow Xcode, which bookkeeps all code
coverage representations in the IDE as absolute paths, to present code
coverage information in the gutters and test results.

This is the third in a stack of PRs across three repositories.

- bazelbuild/apple_support#491
- bazelbuild/rules_swift#1623
- #3250 <-- you are here

It takes the approach suggested in
#1119 and applies it in a way that
scales better between codebases. By breaking sandboxing rules and
remapping a derivable path to the source root, we can to allow Xcode,
which book-keeps all code coverage representations in the IDE as
absolute paths, to present code coverage information in the gutters and
test results. It creates a new config, `rules_xcodeproj_coverage`, and
enables a set of features unconditionally when it is enabled by the
scheme setting that controls the `ENABLE_CODE_COVERAGE` build setting.

This implementation requires #3111 in order for its assumptions to make
sense and be testable.

---

Notes for reviewers, and TODOs:

- This PR requires the changes in those other PRs to work.
- [x] I have tested what happens when you try to use this but those
features don't exist, and **the result was a no-op**.
- This PR does not provide feedback to users that their build will not
be well-cached.
- [x] I have produced a warning diagnostic as part of the build to
inform users, if the features are not set.

---------

Signed-off-by: Aaron Sky <[email protected]>