Intern SimplifyCfg into enum variants

[miguelraz]

EDIT:
WHELP, forgot to rebase to beta. brb in a few.

Was poking around and found that there are only 8 variants that need SimplifyCfg in compiler/rustc_mir_transforms/ - I think they can be shoved into an enum and earn some perf due to reduced (arena) allocations/fetching and compacting.

The variants are

[I] miguelraz@pop-os ~/o/r/c/r/src> rg "new\(\""
lib.rs
302:            &simplify::SimplifyCfg::new("initial"),
342:            &simplify::SimplifyCfg::new("promote-consts"),
474:                &simplify::SimplifyCfg::new("remove-false-edges"),
496:        &simplify_branches::SimplifyConstCondition::new("initial"),
499:        &simplify::SimplifyCfg::new("early-opt"),
537:        &simplify::SimplifyCfg::new("elaborate-drops"),
558:            &o1(simplify::SimplifyCfg::new("after-uninhabited-enum-branching")),
575:            &o1(simplify_branches::SimplifyConstCondition::new("after-const-prop")),
582:            &o1(simplify_branches::SimplifyConstCondition::new("final")),
584:            &o1(simplify::SimplifyCfg::new("final")),

shim.rs
97:            &simplify::SimplifyCfg::new("make_shim"),

Note that a comment in simplify.rs says

  10   │ //! On the other side of the spectrum, the `SimplifyCfg` pass is considerably cheap to run, thus
  11   │ //! one should run it after every pass which may modify CFG in significant ways. This pass must
  12   │ //! also be run before any analysis passes because it removes dead blocks, and some of these can be
  13   │ //! ill-typed.

so I'm hoping for some low-hanging perf fruits here, but the benchmarks will tell.

I plan to also intern the SimplifyConstCondition, but this had tests passing locally so I wanted to push it now.

This is my first rust-lang PR, any feedback is appreciated. Thanks!

[rustbot]

r? @albertlarsan68

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

[rustbot]

⚠️ Warning ⚠️

• These commits modify submodules.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

These commits modify the Cargo.lock file. Random changes to Cargo.lock can be introduced when switching branches and rebasing PRs.
This was probably unintentional and should be reverted before this PR is merged.

If this was intentional then you can ignore this comment.

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

The Miri subtree was changed

cc @rust-lang/miri

[albertlarsan68]

I think you messed up while rebasing, see the documentation.
Also, I'm not the right person to review.
r? compiler

[albertlarsan68]

cc @eholk