This removes an unnecessary lockfile entry.

The module extension is kept in place so that `use_extension` calls
don't need to be updated. The repo rules are moved into a separate file
so that WORKSPACE setups don't fail on a cyclic load of
`bazel_features`. The newly exposed repo rules are protected by load
visibility.

This was removed upstream, only used in tests

…stardoc (#419)

When doing multi-platform builds, using --cxxopt and friends ends up
modifying the toolchain for both OSX, and any target. rules_cc provides
environmental variables to modify the toolchain (which can be modified
through --repo_env), which get around this issue. Add support here for
them too.

Signed-off-by: Austin Schuh <austin.linux@gmail.com>

Add support for generating a .dSYM file if this is requested using
`--apple_generate_dsym`. This change contains the following patches:

* Add `DSYM_HINT` flags to be picked up by `wrapped_clang` to generate
.dSYM bundles on request.
* In `wrapped_clang.cc` make sure the linked binary is stripped after
generating the .dSYM bundle first to make the .dSYM bundle contain
useful information.

Adopts [changes](bazelbuild/bazel#25881) in
bazel to support .dSYM files (as part of fixing
bazelbuild/bazel#16893).

This is needed for LTO builds, this is the path to which linker writes
one big object file after performing link time optimisations, and then
this object file would be used during final linking to create the App
binary, without this file binary would contain invalid debug symbols,
more info - bazelbuild/rules_swift#1529 .

To enable this you need to pass `bazel build --features=full_lto` or
`bazel build --features=thin_lto`, along with `rules_swift` LTO
features.

Closes - bazelbuild/rules_swift#1529

I've needed this behavior in the past and was able to get something that
works but don't know what the best home would be for such a rule. This
seemed to be the most appropriate place I could find in place of adding.
Looking forward to see if maintainers here agree and if so some
feedback!