Rule Request: extend `pattern_matching_keywords` to support non-switch usages, prefer/prohibit outer `let`/`var`

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

New rule request

pattern_matching_keywords will currently only catch violations that occur in switch statements, and will not apply to if case, for case, or while case where they may also be useful. Additionally, it would be great if there were an option to support either never or always put the var and let on the outside, since this can help enforce a consistent style in a codebase.

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.

pattern_matching_keywords does a good job of reducing redundancy for switch statements and can apply more widely to other uses of pattern matching.

Certain code bases may prefer a certain direction. For instance, Google's Swift Style Guide prohibits the shorthand let/var binding variant, as does AirBnb's Style Guide. A number of other style guides state no opinion on this matter, and we prefer outer bindings (case let) in the company I currently work for.

2. Provide several examples of what would and wouldn't trigger violations.

Triggering examples:

// when shorthand_bindings: prefer
case (.some(let x), let y)
if case (.some(let x), let y) = foo
for case (.some(let x), let y) in foo
while case (.some(let x), let y) = foo

// when shorthand_bindings: prohibit
case let (.some(x), y)
if case let (.some(x), y) = foo
for case let (.some(x), y) in foo
while case let (.some(x), y) = foo

Non-triggering examples:

case let x // single bindings should never trigger rule
case let .some(x) // single bindings should never trigger rule
case (let x, let y, z) // should not trigger when `shorthand_bindings: prefer` because of matching variable

3. Should the rule be configurable, if so what parameters should be configurable?

The rule should be configurable in two dimensions:

1. To specify various contexts where this rule should be applied (switch, if, where, for, all)

2. To specify either prohibiting or preferring shorthand bindings

3. Should the rule be opt-in or enabled by default? Why?

pattern_matching_keywords is an already existing rule and is opt-in. Any modifications shouldn't change this fact.

Start by reading the existing pattern_matching_keywords rule and its current switch-statement behavior. Define how the rule should handle if case, for case, and while case, including the configurable context and shorthand-binding preferences, then verify the triggering and non-triggering Swift examples in the issue.