Feature request: Add a bazel Runnable kind

[petr-tik]

As a developer using rust-analyzer with bazel (using rules_rust and rust-project.json generated by @rules_rust//tools/rust_analyzer:gen_rust_project)
I would like rust-analyzer to use bazel test for test runnables
so that I can enjoy the same UX regardless of the build system.

The Runnables extension is a great productivity boost and it's very easy to run a test
from a code lens. According to my experiments and the lsp-extensions.md documentation, it
currently only supports one Runnable.kind = "cargo".

Given the consistency and stability of the bazel test intereface, we should be able to use bazel test and pass additional command line arguments

bazel test //path_to_rust_package:rust_test_name --test_arg $THE_TEST_SELECTED_BY_USER

While the --test_arg is definitely something that rust-analyzer can already reliable populate, working out the //path_to_rust_package:rust_test_name might require an expansion to rules_rust to add test targets to rust-project.json file.

Once this is implemented, the same interface could be used for the Related Tests extension.

For rust-analyzer to automatically work out the runnable kind is "bazel", rules_rust can add a field to rust-project.json that declares runnable kind to be bazel (or we can heuristically guess?).

For the rest, rust-analyzer works like a charm with bazel, so thanks very much.

[googleson78]

Another idea is to have overrideCommand for the tests, like what is done for checkOnSave

[matklad]

Yup, we should have something like this. The runnables infra was originally designed with an eye towards something extensible like this (hence runnable kind existance).

One designed constraint here is that we should glue bazel and rust-analyzer here in such a way so as not to hard-code knowledge about bazel.

Ideally, the runnables LSP request exposes only semantic knowledge (eg, "there's a test in target spam with name foo::bar::baz"), and then there's some other extension (bazel-rust-analyzer) which cooks up the specific command line string to launch.

The reason for this enterprisey setup is that there are many ways to launch things. Ie, we can imagine running a test, in debugger, on embedded device and such. So we should provide customization points outside of rust-analyzer process proper to do these fancy things.