feat: Implement builtin#format_args, using rustc's format_args parser

[Veykril]

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 #15082
cc rust-lang/rust#110680

[Veykril]

Note this currently copies rustc's format_args parser crate, as it depends on rustc_datastructures and I am waiting for my upstream PR to get merged at which point we can depend on a published copy of it instead, hence why the PR is even more massive than it should be

[Veykril]

exprs: 662115, ??ty: 30 (0%), ?ty: 116 (0%), !ty: 3
pats: 155657, ??ty: 4 (0%), ?ty: 5 (0%), !ty: 0

This does increase analysis-stats mir memory consumption by ~80 mb though, definitely something we wanna take a look at again (as in to optimize if possible). That makes me wonder if there is some easy to write MIR opt that can optimize for MIR size?

[Veykril]

Note, (I'm probably not fixing this in this PR) format_args_nl! will behave the same as format_args! that is no newline will be appended. This is fine for most hings but mir eval.

[Veykril]

I'm unsure how to solve this, we could give the construct an extra "parameter" or something that tells it to emit an additional newline, make a builtin#format_args_nl construct or try to fiddle with the template string which I really do not want to do (and I don't think we can reasonably do that).

[Veykril]

I'm leaning towards adding a second builtin# variant, it seems simplest

[Veykril]

Let's see how this goes
@bors r+

[bors]

📌 Commit 96f1923 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 96f1923 with merge f29867b...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing f29867b to master...

[HKalbasi]

That makes me wonder if there is some easy to write MIR opt that can optimize for MIR size

Yes, there are some easy optimization passes that we can implement. Generating a better MIR in first place is also something we can try, which may achieve somethings that easy optimizations can't.

Looks like debug render on hover is still broken though, so something fails in mir eval still

Yes, also failed mirs on self count is 2488, while I hoped it to be dropped to near zero after this PR. Will look at it.