rust-analyzer root discovery should support configurable target query

Written by AI, reviewed by human to be a real issue.

## Description

`discover_bazel_rust_project` falls back to `//...` for no-argument/root rust-analyzer discovery. In large mixed Bazel workspaces, that broad target pattern can make rust-analyzer project generation analyze non-Rust targets, incompatible targets, or targets that only fail under the forced rust-analyzer platform/configuration.

This makes root discovery fragile and expensive even when the workspace has a clear smaller set of Rust targets that should be used for rust-analyzer.

## Current behavior

When rust-analyzer invokes discovery without a source-file argument, `discover_bazel_rust_project` resolves the target pattern to `//...` and passes that to `generate_rust_project`.

For mixed workspaces this can fail before producing `rust-project.json`, or produce a much larger project than needed, because Bazel has to analyze targets that are irrelevant to Rust editing.

## Expected behavior

There should be a supported way to configure the root discovery target set, for example by passing a Bazel query used only when no source-file argument maps to a more specific package target.

For example, a workspace could configure root discovery to query only Rust targets or only curated top-level Rust targets, while source-file discovery continues to use the existing package-scoped behavior.

## Reproduction shape

1. Use a Bazel workspace containing Rust targets plus non-Rust or platform-specific targets.
2. Configure rust-analyzer to use `discover_bazel_rust_project` at the workspace root.
3. Trigger root discovery with no source-file argument.
4. Observe that discovery analyzes `//...`, which can include unrelated or incompatible targets and fail or become very slow.

## Impact

This hurts rust-analyzer setup for monorepos and mixed-language Bazel workspaces. Users who only need a Rust-focused target set cannot express that through the discovery tool, so the default `//...` behavior becomes the limiting factor.

## Possible solution

Add a root-discovery-only query option such as:

```sh
--root-target-query='kind("rust_.* rule", //...)'
```

When no rust-analyzer source-file argument maps to a package target, run that query and pass the resulting labels to project generation. When rust-analyzer asks about a specific source file, keep the existing package-scoped target discovery.

Start by locating discover_bazel_rust_project and generate_rust_project, then trace how the no-argument path resolves //... and how source-file discovery selects package-scoped targets. Add a root-only target-query option so configured labels are used without changing source-file discovery, and verify that project generation uses the selected root targets.

Written by the indexing model from the issue text.