Implement `write_via_move` intrinsic for mir-eval
Required for getting `write!`ing to work again. we fail with an odd type mimsatch eval error after this change though
internal: use current folder's `rustfmt.toml` with all rustfmt configurations
## Introduction
Resolves https://github.com/rust-lang/rust-analyzer/issues/15540. I moved the `chdir` functionality outside of the `match` to ensure that this functionality wouldn’t fall through again. As part of this PR, I also changed `from_proto::file_range` to accept a `TextDocumentIdentifier` by reference instead of by value, but I can undo this change if desired.
## Testing
I added a `rustfmt.toml` will the contents below at `crates/rust-analyzer/rustfmt.toml`:
```toml
reorder_modules = false
use_small_heuristics = "Max"
# this is the only difference from the `rustfmt.toml` at the root of the repo
tab_spaces = 8
```
In addition, I've also added `"rust-analyzer.rustfmt.overrideCommand": ["rustfmt"]` to my VS Code configuration.
With the above changes, saving `crates/rust-analyzer/src/handlers/request.rs` results in 8-space indentation. Meanwhile, saving `crates/toolchain/src/lib.rs` _does not_ result in any formatting changes.
Implement builtin#format_args, using rustc's format_args parser
`format_args!` now expands to `builtin#format_args(template, args...)`, the actual expansion now instead happens in lowering where we desugar this expression by using lang paths.
As a bonus, we no longer need to evaluate `format_args` as an eager macro which means less macro expansions overall -> less cache thrashing!
Fixes https://github.com/rust-lang/rust-analyzer/issues/15082
Bump `rustc-perf` checkout for metrics, replace webrender, diesel and ripgrep with newer versions
The previous versions were removed hence the updates. The metric results for the changed ones are disconnected now as to not muddle things up.
I think it's worth it for us to occasionally bump the `rustc-perf` checkout, as it allows us to include more interesting new targets.
Notably, the newer diesel is 3 times as fast to analyze as the one of the current checkout.
Add a few more `db.unwind_if_cancelled()` calls
Judging from a profile sent by a friend, the borrowck query took up a significant amount of time in their project which might be the cause for some unresponsiveness as nothing in the mir stack currently unwinds on cancellation
Shuffle some locking around
The main thread is still occasionally blocking on something and I am unsure what the cause might be. This will hopefully help somewhat
