Adapt rules based toolchain to work on other platforms (#623)

With expanding Swift toolchain support in rules_swift, for many
platforms, we need
a cc toolchain that potentially uses Apple's clang that ships with Swift
on Linux.

This lets us re-use the majority of our Apple toolchain but for
targeting embedded
or linux. This means we don't have to worry about incompatibilities from
a host gcc
toolchain, or a mismatched clang version toolchain. Users wouldn't
particularly
have to use this still, but it's a better default than what rules_cc
gives us.
Since we're already downloading the Swift toolchain that has clang in
rules_swift
there's also no downside there.

Add gazelle for bzl_library generation (#612)

Fix releases (#597)

BCR uses the tests dir so we can just keep it in the archives, it's
small enough anyways. We've fixed upstream compat as well.

This requires updating skylib for the `scope` attr

Use BCR github action over github app (#501)

The github app is going away. This publish workflow was unused, now it's
directly part of the create-release.yml

Move xcode_configure to this repo (#577)

This already references rules that live in this repo, so might as well
move the repository_rule here too. This makes it easier to make
additions to the rules as well

feat: Do not add objc, lkmod, lkmodc++, etc build when building iOS k…

…ernel extensions (#570)

Support bazelbuild/rules_apple#2911 by not
adding objective c, kmod, kmodc++ libraries when building iOS kernel
extensions.

1. Objective C doesn't work inside the iOS/macOS kernel
2. kmod and kmodc++ libraries are macOS only. The libkmod.a and
libkmodc++.a artifacts in the macOS SDK will not build for iOS kernel
extensions

Realistically the solution for 2 is that we provide the rest of the
symbols that are provided by `libkmod.a` and `libkmodc++.a` ourselves in
the kext source code ourselves.

Example symbols

`_start`
`_stop`
`_OSKextGetCurrentIdentifier`
`_OSKextGetCurrentLoadTag`
`_OSKextGetCurrentVersionString`

Co-authored-by: YungRaj <yung.raj919@gmail.com>

Fix dotd validation with bazel 9.x (#566)

With 9.x bazel's default output_base on macOS changed to
`~/Library/Caches`. Previously we included `~/Library` in the system
include path allowlist that is consulted for dotd validation. That
meant any file in the output_base would be assumed to be allowed even if
it wasn't correctly defined in BUILD files.

`~/Library` is used for `~/Library/Toolchains` for custom Swift
toolchain installations that don't require `sudo` to install.
Technically you can also install the CLT there, but I imagine that would
break many other things. We now scope this better to exclude
`~/Library/Caches`

Fix -F flags to C++ compiles (#565)

I broke this in 643fa0f by assuming the
fact that the features weren't `implies`ed by cpp compile meant they
weren't used in that action

Enable support for layering_check by default (#557)

This still requires users set `--features=layering_check` or
`features = ["layering_check"]` in user's configs, but now those will
actually run on macOS. This can still be disabled by setting
`--repo_env=APPLE_SUPPORT_LAYERING_CHECK_BETA=0` in case there are
issues. The biggest potential issues I see are big projects with macOS
only libraries that are unknowingly broken with layering checks, or the
modulemap generation step being too slow / broken for some case.

Add -DDEBUG and -O0 for dbg compiles (#556)

In the past for Objective-C these came from
incompatible_avoid_hardcoded_objc_compilation_flags, which was flipped
in bazel 9.x. We pass these 2 for fastbuild as well.