Migrate toolchain configuration to rules_toolchains

@armandomontanez and I have been working on improving toolchain configuration for C++, and we presented our work at bazelcon last year ([youtube video](https://www.youtube.com/watch?v=PVFU5kFyr8Y), [slides](https://static.sched.com/hosted_files/bazelcon2024/89/Creating%20C%2B%2B%20toolchains%20easily.pdf?_gl=1*6e9e1o*_gcl_au*MjA3MTAwMTQ0Mi4xNzM2NDYyMzk4*FPAU*MjA3MTAwMTQ0Mi4xNzM2NDYyMzk4)). Recently, I started working on decoupling this work from rules_cc.

I recommend looking at the example lang_library definition [here](https://github.com/matts1/rules_toolchains/blob/push-owtrzskvwktx/examples/rules_lang/lang/defs.bzl#L9-L36) and the toolchain definition [here](https://github.com/matts1/rules_toolchains/blob/push-owtrzskvwktx/examples/rules_lang/lang/toolchain/default_toolchain/BUILD) to see how rules_rust would makke use of it. It is most definitely not ready for use yet, but I wanted to ask whether rules_rust would be interested in onboarding.

The TLDR of how it works is that rules_rust would come up with a bunch of different actions (eg. compile, link, proc_macro_compile), and then rather than running `ctx.actions.run`, you would just call `run_action(action_type = compile, variables = struct(source_files = [main.rs], libraries = [foo.dylib], output_file = [main], features = ["foo"], static = False, sysroot = path/to/sysroot)`, and the toolchain config would then calculate what tool to use, what input files it requires, and the command-line invocation to run.

A quick skim of issues on the issue tracker reveals that it can solve a variety of issues that commonly pop up, such as #2833, #1711, #1034, #3045, #2701 and #1623.

I believe that in the future, most toolchains will migrate to this, as it makes rulesets significantly easier to write, and makes toolchains far more customizable with zero effort from the ruleset maintainer.