feat: Add incorrect case diagnostics for enum variant fields and all variables/params Updates the incorrect case diagnostic to check: 1. Fields of enum variants. Example: ```rust enum Foo { Variant { nonSnake: u8 } } ``` 2. All variable bindings, instead of just let bindings and certain match arm patters. Examples: ```rust match 1 { nonSnake => () } match 1 { nonSnake @ 1 => () } match 1 { nonSnake1 @ nonSnake2 => () } // slightly cursed, but these both introduce new // bindings that are bound to the same value. const ONE: i32 = 1; match 1 { nonSnake @ ONE } // ONE is ignored since it is not a binding match Some(1) { Some(nonSnake) => () } struct Foo { field: u8 } match (Foo { field: 1 } ) { Foo { field: nonSnake } => (); } struct Foo { nonSnake: u8 } // diagnostic here, at definition match (Foo { nonSnake: 1 } ) { // no diagnostic here... Foo { nonSnake } => (); // ...or here, since these are not where the name is introduced } for nonSnake in [] {} struct Foo(u8); for Foo(nonSnake) in [] {} ``` 3. All parameter bindings, instead of just top-level binding identifiers. Examples: ```rust fn func(nonSnake: u8) {} // worked before struct Foo { field: u8 } fn func(Foo { field: nonSnake }: Foo) {} // now get diagnostic for nonSnake ``` This is accomplished by changing the way binding identifier patterns are filtered: - Previously, all binding idents were skipped, except a few classes of "good" binding locations that were checked. - Now, all binding idents are checked, except field shorthands which are skipped. Moving from a whitelist to a blacklist potentially makes the analysis more brittle: If new pattern types are added in the future where ident pats don't introduce new names, then they may incorrectly create diagnostics. But the benefit of the blacklist approach is simplicity: I think a whitelist approach would need to recursively visit patterns to collect renaming candidates?