Auto merge of #15560 - davidbarsky:davidbarsky/use-sysroot-rustc-to-determine-cfgs, r=Veykril

project-model: when using `rust-project.json`, prefer the sysroot-defined rustc over discovery in `$PATH`

At the moment, rust-analyzer discovers `rustc` via the `$PATH` even if the `sysroot` field is defined in a `rust-project.json`. However, this does not work for users who do not have rustup installed, resulting in any `cfg`-based inference in rust-analzyer not working correctly. In my (decently naive!) opinion, it makes more sense to rely on the `sysroot` field in the `rust-project.json`.

One might ask "why not add `rustc` to the `$PATH`?" That is a reasonable question, but that doesn't work for my use case:
- The path to the sysroot in my employer's monorepo changes depending on which platform a user is on. For example, if they're on Linux, they'd want to use the sysroot defined at path `a`, whereas if they're on macOS, they'd want to use the sysroot at path `b` (I wrote the sysroot resolution functionality [here](https://github.com/facebook/buck2/blob/765da4ca1e0b97a0de1e82b2fb3af52766fd06f4/integrations/rust-project/src/sysroot.rs#L39), if you're curious).
- The location of the sysroot can (and does!) change, especially as people figure out how to make Rust run successfully on non-Linux platforms (e.g., iOS, Android, etc.) in a monorepo. Updating people's `$PATH` company-wide is hard while updating a config inside a CLI is pretty easy.

## Testing

I've created a `rust-project.json` using [rust-project](https://github.com/facebook/buck2/tree/main/integrations/rust-project) and was able to successfully load a project with and without the `sysroot`/`sysroot_src` fields—without those fields, rust-analyzer fell back to the `$PATH` based approach, as evidenced by `[DEBUG project_model::rustc_cfg] using rustc from env rustc="rustc"` showing up in the logs.

0 files changed, 0 insertions, 0 deletions