Add rule for visually pleasing formatting of long guards

New Issue Checklist

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

Rule Request

I'd like to suggest a rule for enforcing the style

guard
    let a = ...,
    let b = ...,
    let c = ...
else {
    return ...
}

for guard statements where the (binding) conditions don't fit into a certain line length.

1. Why should this rule be added?

The proposed style clearly separates the condition from the body and keeps the indentation of the body consistent with the outer scope.

The currently allowed styles for long guards are

guard let a = ...,
    let b = ...,
    let c = ... else {
        return ...
}

guard let a = ...,
    let b = ...,
    let c = ... else {
    return ...
}

guard let a = ...,
      let b = ...,
      let c = ... else {
    return ...
}

The first one moves the else body in by two levels as compared to the outer scope which IMHO breaks the reading flow.

The second option has consistent indentation in the body but the condition lines following the first line have the same indentation which makes it hard to visually tell the end of the condition and the beginning of the body apart.

The last one, finally, uses an indentation for the condition lines that is not a multiple of the base indentation level in the rest of the code (here 2 spaces instead of 4) which IMHO is bad for readability as well.

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

Not ok:

See above, and

---------------------------------------| Line length limit
guard let a = ..., let b = ..., let c = ... else {
    return ...
}

Ok:

---------------------------------------| Line length limit
guard let a = ..., let b = ... else {
    return ...
}

---------------------------------------| Line length limit
guard
    let a = ...,
    let b = ...,
    let c = ...
else {
    return ...
}

See above.

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

Yes, the severity level and the threshold line length.

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

Opt-in because not everyone might like this style.

The issue defines a new opt-in rule for formatting long Swift guard conditions, including configurable severity and line-length threshold, but names no implementation files or tests. Start by locating SwiftLint's existing rule implementations and their tests; done means the requested guard layout is diagnosed consistently while accepted layouts remain valid and the rule is opt-in.