`contrasted_opening_brace` false positives in trailing closures and `else if` statements

[buresdv]

New Issue Checklist

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

Feature or Enhancement Proposal

I'm using the new contrasted_opening_brace rule. I ran across a potential false positive (at least in my opinion) when this rule is used on trailing closures that include parameters.

Examples include (lifted straight from my codebase):

return allDependencies.map
{ dependency in // <-- Violation here
    .init(name: dependency.fullName, version: dependency.version, directlyDeclared: dependency.declaredDirectly)
}

let originalServicesWithTheirUUIDs: [String: UUID] = services.reduce(into: [:])
{ result, originalService in // <-- Violation here
    result[originalService.name] = originalService.id
}

return AsyncStream
{ continuation in // <-- Violation here
}

I'd expect this rule to not consider these examples violations. Perhaps there could be a setting that would not flag these.

[buresdv]

Some closures report a false positive even without the parameters:

Text("add-package.install.wrong-architecture.title")
        .onAppear
        { // <-- Violation here
            packageInstallationProcessStep = .wrongArchitecture
        }

Text(currentMaintenanceStepText)
        .task(priority: .userInitiated)
        { // <-- Violation here
        }

Another potentionally related false positive occurs in long else-if chains (don't judge me 😅 )

There's also another potential false positive in this case, which I'm not sure how to describe (perhaps I should make a separate issue for this one?)

[buresdv]

@SimplyDanny you're the man

[SimplyDanny]

@buresdv: Formatting rules often rely on heuristics and so does this rule now especially in terms of the fixes I made to cover your reported misbehavior. So you might find other issues afterwards which we need to address in an iterative manner.