Fix broken SwiftLint rules and add missing SwiftLint rules

[fixpunkt]

We need to write a few more SwiftLint lints for style conventions which are important to us, but which SwiftLint does not support yet:

• return must be preceded by a blank line unless it is the only statement in a block. (Add new rule to SwiftLint for linting newlines before return statements #47)
• Multiline method / function parameter declarations must have one parameter per line, with the first parameter starting on a new line and the closing parenthesis on a line by itself as in PSR-2.
• Disable line_length when most of the line is a string literal.
• // swiftlint:disable:next directive comments should have an explanatory text formatted like // swiftlint:disable:next line_length -- exceeding line_length is better than using concatenation to break a string literal here.
• multiline_function_chains is buggy when chaining promises (e.g. it will trigger on https://github.com/VIISON/POSApp/blob/479c76811bcecbcfa5a909421505f783f2fc43a3/POS/Controllers/Alerts/ShouldChangeCustomerGroupAlert.swift#L46) - we need to fix this and re-enable it.
• modifier_order sometimes fails to respect the atPrefix before public configuration, which causes it to behave erratically. Because of this, we had to disable the rule. Since we actually want this rule, we should fix it.
• closure_end_indentation is buggy when the expression that declares the closure's opening brace is not the first expression on its line, e.g:

  foo(
      bar: ""
  ).then { _ in
      // baz
  }.done { _ in // <-- false positive in this line
      // baz
  }

• opening_brace is buggy when implicitly returning a closure from a map() etc., e.g.

  let result = [1, 2, 3].map { value -> (() -> Void) in
      { print("value is \(value)") } // <-- false positive in this line
  }

• Add config option to discouraged_optional_collection and ImplicitlyUnwrappedOptionalConfiguration for ignoring override properties.
• vertical_whitespace_opening_braces is buggy when the first member of a scope is a comment, e.g.

  struct Foo {
  
      // MARK: - Foo
      var foo: String
  }

• colon is buggy when moving protocol conformances to separate lines in type declarations:

  class Foo:
      String,
      Equatable
  {
      // ...
  }

• Idea: Add an analyzer rule that checks types fo conformance to ExpressibleByStringLiteral and that respective initializations use strings.
• operator_usage_whitespace does not apply to ranges (e.g. 0..<count)
• overridden_super_call does not trigger on missing super call

  internal override func setup() {
      // We need to set a slightly darker color for the disabled state, that doesn't conform to the design specification,
      // because we are creating the "inverted" background color via the tint color that is used also for the text.
      // Otherwise the color from the design-guide would be too light.
      self.disabledColor = .gray
  }

• unused_declaration produces false positive for Swift 5.2 callable values, i.e. func callAsFunction)
• explicit_self produces false positive for access to a projectedValue of @propertyWrappers, i.e. foo.$bar (Fix false positive in SwiftLint rule explicit_self when using projectedValue of a property wrapper #67)

[fixpunkt]

This is the modifier_order config we settled on:

modifier_order:
    - atPrefixed
    - final
    - override
    - required
    - convenience
    - lazy
    - dynamic
    - acl
    - setterACL
    - owned
    - mutators
    - typeMethods

[svenmuennich]

I enabled modifier again via f85bbeb

[svenmuennich]

Since SwiftLint v0.34.0 it is possible to an explanation to a swiftline:disable comment by separating it using -.