Optional features are part of the crate — the project should say so

A hint from cargo.toml for rust-analyzer can be used to include optional features. But for that to make sense it should also benefit Cargo, and I don't know enough about Cargo's design to say if that's justified.

Rust-analyzer already has the ability to read project settings. It respects [env] from .cargo/config.toml. Though I believe it does so through Cargo, not by parsing the file directly (Somebody might confirm this). Since work on rust-analyzer support is experimental (could not make it work yet), it would make it easier to also read their own keys from .cargo/config.toml. The experiment does give me the idea that there is a demand for project-level config. I think my proposal is also an addition to the rust-analyzer config file.

In general, I think of it this way:

• Project intent -> shared defaults .cargo/config.toml
• User preference -> local settings rust-analyzer.toml
• Editor choice -> editor-specific settings (e.g. .vscode/, .zed/)

All three can be version controlled separately if preferred.

Project-level config could go in rust-analyzer.toml, but then there's no clean distinction between a crate's suggestion and a user preference. As rust-analyzer already uses [env] from .cargo/config.toml, it makes sense to also use it to set defaults. Using a cargo config also works in workspaces.