Add a comment pointing to ICE-136223
Fixes#136223
## Steps how the ICE happen
This explanation is based on the test case `&Some(Some(x)) = &Some(&mut Some(0))`.
The case should fail with E0596 error, but it catches the debug assertion instead.
1. For the first `&`: In check_pat_ref(), the value max_ref_mutbl becomes MutblCap::Not ([here](fdd1a3b026/compiler/rustc_hir_typeck/src/pat.rs (L2394-L2396))). Once max_ref_mutbl becomes Not, it will never be back to MutblCap::Mut.
2. For `&mut`: In peel_off_references(), because Some(x) doesn't have `&` nor `&mut`, `&mut` in `&mut Some(0)` is not consumed then default_binding_mode (def_br) becomes `ByRef::Yes(Mutability::Mut)` (around [here](fdd1a3b026/compiler/rustc_hir_typeck/src/pat.rs (L519-L536))). This will be inherited to the next step. So this pattern has the mismatch between `def_br=Yes(Mut)` and `max_ref_mutbl=Not` now.
3. For the value `0`: Because of the step 2, the default_binding_mode is `Yes(Mut)`, but max_ref_mutbl is `Not` from the step 1. It causes the assertion error [here](fdd1a3b026/compiler/rustc_hir_typeck/src/pat.rs (L427-L430)).
## What this PR fixes
Step 1 has happened from [this commit](e2f3ce9568) by deleting `no_ref_mut_behind_and` from the if block. In my understanding, after RFC3627 is released, step 1 should happen not only 2024 edition but also other editions to track MutblCap value. But for now, it should not happen for non-2024 edition. So I put it back.
NOTE: I think there is another solution - We should return an E0596 error in calc_default_binding_mode() instead of the debug assertion. Since the assertion is caused by the mismatch between `def_br = Yes(Mut)` and `max_ref_mutbl = Not`, but in my understanding this violation is the same as E0596. check_pat_ident() does returns E0596 by a similar reason [here](fdd1a3b026/compiler/rustc_hir_typeck/src/pat.rs (L837-L856)).
ef22c14dfb