[Perf Experiment] Introduce NeverShortCircuit to see if it helps fold-via-try_fold

[scottmcm]

This was removed a while ago for compilation time reasons, but the user experience would be better if implementing just try_fold was enough to also get optimized fold -- and at the LLVM level that completely works.

Since the removal we've moved to a different Try implementation, so this PR tries adding an as-simple-as-possible repr(transparent) newtype NeverShortCircuit in hopes that will minimize any perf regressions (as it won't need to test From impls and such, like it used to back in the try_trait_v1 days).

r? @ghost

[scottmcm]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit bdef2ad with merge 6f42da510ae8aeb7f33b36463a98f35e72a14d91...

[scottmcm]

@rust-timer build 6f42da510ae8aeb7f33b36463a98f35e72a14d91

[rust-timer]

Queued 6f42da510ae8aeb7f33b36463a98f35e72a14d91 with parent b416e38, future comparison URL.

[rust-timer]

Finished benchmarking commit (6f42da510ae8aeb7f33b36463a98f35e72a14d91): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -0.4% on incr-unchanged builds of wg-grammar)
• Large regression in instruction counts (up to 2.5% on incr-patched: println builds of clap-rs)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[scottmcm]

Hmm, mostly 0.1% regressions but a couple over 1%. Promising, but not clean enough to be obviously-fine.

Seeing 1% regressions on check builds makes me think there's an opportunity to improve that, since the implementation of a function in core really shouldn't matter for that...