Rule Request: Prefer `for case let` when nil tuple members are skipped

New Issue Checklist

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

Rule Request

We should prefer for case let when nil tuple members are skipped. For example, the general pattern

for (n1, n2, ...) in <sequence> {
  guard let nX = nX else {
    continue
  }
  // body
}
// or
for (n1, n2, ...) in <sequence> where nX != nil {
  // body
}

should be corrected to:

for case let (n1, n2, nX?) in <sequence> {
  // body
}

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

Rule should be added because it makes for more readable and concise code.

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

Here's a before/after commit from SwiftLint itself (a02d4e17ddcb35ddd2006da60ce83efa5e8f58c4)

-for (pattern, operatorString) in [toPattern, toNotPattern] {
-    guard let operatorString = operatorString else {
-        continue
-    }
-
+for case let (pattern, operatorString?) in [toPattern, toNotPattern] {

Would trigger:

for (n1, n2, ...) in <sequence> {
  guard let nX = nX else {
    continue
  }
  // body
}
// or
for (n1, n2, ...) in <sequence> where nX != nil {
  // body
}

Wouldn't trigger:

for case let (n1, n2, nX?) in <sequence> {
  // body
}
// or
for (n1, n2, ...) in <sequence> {
  // body, not skipping nX immediately or unconditionally
}

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

Should only be configurable on severity.

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

Enabled by default. I can't think of too many cases where you wouldn't want this.

Start by examining the referenced SwiftLint commit a02d4e17ddcb35ddd2006da60ce83efa5e8f58c4 and the repository's existing rule implementations and tests. Determine how comparable loop-pattern rules are structured and tested. Done means the requested for case let preference is detected, non-matching examples are accepted, and severity is configurable.