Add override point for cc_autoconf

[keith]

This adds overriden_labels to the cc_autoconf rule. This allows to
override specific tools that bazel uses when setting up
local_config_cc. The benefit there is that if you want to replace
pieces of the cc toolchain, without having to create your own crosstool
entirely, this allows you to do that.

Specifically for the osx toolchain sometimes overriding flags in
response to Xcode updates, without having to wait for a bazel release is
useful. If we're ok with this approach this could also be extended to support overrides for other platform's setup.

[keith]

With this change, here's an example of how you can override a tool:

cc_autoconf(
    name = "local_config_cc",
    overriden_labels = {
        "@bazel_tools//tools/osx/crosstool:osx_archs.bzl": "@lyftios//:foo.bzl"
    },
)

bind(
    name = "cc_toolchain",
    actual = "@local_config_cc//:toolchain",
)

register_toolchains(
    "@local_config_cc//:all",
)

[keith]

I wanted to submit this PR as a discussion for how we could provide easier ways for users to override specific pieces of this setup, without having to override the whole thing. Recently we've discovered some issues in the crosstool that have required us to either find a workaround, wait for the next bazel release, or create our own crosstool. Having this would make it easier to override those specific pieces temporarily, until the next bazel release.

[keith]

@hlopko can you review?

[hlopko]

I grew paranoid of changing cc_configure. We have very little test coverage, and we have very frequent cherry picks into Bazel releases because of cc_configure bugs. So I'd prefer if you commented on #6926 to make sure your use case is well understood and addressed by the redesign. If there is an urgency to land this PR, let us know. Thanks!

[keith]

We've had a significant number of issues that required crosstool changes, having to wait for releases after our changes have landed has definitely pushed us to consider creating our own crosstool quite a few times. I think forcing users towards creating their own crosstool should be an antigoal because that will lead to fewer upstream fixes to the crosstool here.

There isn't a huge specific rush from our perspective on landing this (although we did just have to upgrade to the 0.25.0rc2 because of this crosstool bug #7830 that hasn't been released yet), but if those changes aren't coming soon I think it would be great to have this interim solution.

[keith]

@hlopko any other thoughts?

[keith]

@hlopko friendly ping

[katre]

@hlopko is out of office until next week. @scentini, can you comment?

[keith]

@hlopko friendly ping

[keith]

We hit another case where this patch would come in handy where we need this patch a8fa6e2 but can't update to the 0.26.0rc8 because of a crasher #8364

[keith]

@hlopko or @scentini any thoughts?

[hlopko]

Hi Keith, sorry for keeping you waiting. I don't think we'll merge this PR before somebody sits down and thinks (and designs, and tests) how cc_configure should be customized and what is supported and part of the public contract. Right now cc_configure lives its own organic life which is not maintainable anymore.

We're also in the process of moving cc_configure to @rules_cc and slowly trying to get it under control (= have any test coverage). So I'd say it's not the right time.

[hlopko]

Actually, I'm sorry but I'll close this PR now. I'll make sure to include you in the future design discussions of cc_configure. Thank you so much!