`#[optimize]` does not fully overwrite global opt level in all MIR opts

Even after https://github.com/rust-lang/rust/pull/160524, some passes still use sess.opt_level/sess.mir_opt_level, which means they do not properly honor #[optimize]:

• The inliner has a very special policy where on mir-opt-level 2, behavior depends on the -Copt-level. This is because -Copt-levels 1..=3 all map to the same mir-opt-level but the inliner does not want to behave the same for all of them. I assume we want to preserve this distinction between -Copt-level=1 and higher values (@wesleywiser @cjgillot I think you added this logic in https://github.com/rust-lang/rust/commit/d1d9092e3c99343e03abc650e91082b5c9f538b9, would be good to hear your thoughts on this). If so, we can either just accept that the attribute is not fully equivalent to changing the global opt level, or we could do it properly: map -Copt-level=1 to a different mir-opt-level than the higher -Copt-level values (but is that worth it if the inliner is the only pass making a distinction between the two?).
• dataflow_const_prop passes checks sess.mir_opt_level inside the actual pass to be more or less aggressive. #[optimize] only affects whether the pass is enabled, but then we don't use the attribute later when the pass runs to determine how aggressive it is. See here, here. Not sure what the best way is to deal with this. Maybe we just accept this?

Cc @clubby789 @veluca93 @rust-lang/wg-mir-opt

Tracking issue: https://github.com/rust-lang/rust/issues/54882

Start in compiler/rustc_mir_transform/src/dataflow_const_prop.rs at the checks linked in the issue, then trace how #[optimize] controls pass enablement and how the inliner reads sess.opt_level and sess.mir_opt_level. Resolve whether #[optimize] must preserve the -Copt-level=1 distinction or accept an exception, and define consistent behavior for dataflow_const_prop. Confirm the chosen policy against the tracking issue and relevant MIR optimization code.