feat: expose toolchains

[rickvanprim]

New Feature

Exposed toolchains so that they can be used independently of registering them with the repo rules.

Test plan

Checked that my code is able to build while using the new public toolchain rules.

[CLAassistant]

All committers have signed the CLA.

[alexeagle]

Since we have tar I'm generally supportive of adding more common tools

[thesayyn]

I don't see where these tools "sed" and "grep" come from

[thesayyn]

i am beginning to think that we should have another ruleset called rules_bash where bring in these tools hermetically. bazel-lib is becoming bloated.

[alexeagle]

https://github.com/tweag/rules_sh is already maintained by some Nix experts 😉

[rickvanprim]

@thesayyn this PR doesn't have actually fetching the tools yet. I wanted buy in on adding this before I put that work in. Plus I'm using this with Nix so I don't actually need that part for my stuff 😅

Regarding rules_bash (or rules_sh), how would you feel about something like toolchains (much like platforms) that just contains the toolchain_types, the providers, and the rules for instantiating the toolchain, so there's a common definition. Actual fetching of the toolchains would belong in other repos. I am discussing this a little bit with @alexeagle and Matt Clarkson on Slack 🙂

[alexeagle]

I think the toolchain_types have to go somewhere else
bazel-contrib/SIG-rules-authors#91

[rickvanprim]

@alexeagle / @thesayyn greatly scoped this down to just exporting the toolchain rules. Also happy to close this and just import them from private in my code if that's preferred.

[alexeagle]

I don't see on this thread an answer to: why would you want to load the toolchain symbols independently from registering them? Any increase to the public API surface constrains what maintainers are able to change, so it should come with an accompanying end-user benefit.

[rickvanprim]

I updated the overall PR description to cover the motivation, which is registering these toolchains without the binaries being provided by aspect_bazel_lib. If that doesn't align with the goals here, we can just close this, and I will just directly import them from the private directory.

[alexeagle]

Sorry we never got to this one. Now that it's in bazel-contrib we have a wider maintainer base. Maybe @fmeum has an opinion about the toolchain_type's being exposed as public API, but I'm still inclined to say it's rare enough that you should just use the private API and deal with unlikely breaking changes

[fmeum]

Until the community stabilizes on best practices for "bunch of files" toolchains, I would also consider it too risky to expose these publicly (see bazelbuild/bazel#19645).

[rickvanprim]

Thanks @alexeagle and @fmeum. I'll just use it privately 🙂