Fix exhaustiveness checking of strings

[Nadrieril]

Before #78430, the code worked because specialize_constructor didn't actually care too much which constructor was passed to it unless needed. That PR however handles &str as a special case, and I did not anticipate patterns for the &str type other than string literals.
I am not very confident there are not other similar oversights left, but hopefully only &str was different enough to break my assumptions.

Fixes #78549

[rust-highfive]

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

[Nadrieril]

After a good night's sleep I found a way of solving the issue that involves fewer footguns. I feel a bit more confident about my solution now.

[Nadrieril]

@varkor it's ready to go

[varkor]

@bors r+

[bors]

📌 Commit 1bdcd02 has been approved by varkor

[bors]

⌛ Testing commit 1bdcd02 with merge 1899c48...

[bors]

☀️ Test successful - checks-actions
Approved by: varkor
Pushing 1899c48 to master...

[Mark-Simulacrum]

A fairly large improvement on perf, up to 10% on instructions and this is reflected with a roughly 3% win on wall times. Good work.

[Nadrieril]

Thanks! I was not expecting a perf gain from this one ^^.
I have to point out that the match-stress-enum benchmark is not representative though. Patterns in the wild almost always have depth and matches don't have more than a couple branches. match-stress-enum has a billion branches and no depth. I think it is good for monitoring hot paths in exhaustiveness checking, but I wouldn't trust it to indicate differences on real workloads.
EDIT: oh I hadn't seen the "bootstrap timings" section, those seem to indicate real gains :o