Merge opposite / possibly conflicting rules & support opposite/similar rule functionality

[rgoldberg]

New Issue Checklist

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

Feature or Enhancement Proposal

Merge opposite / possibly conflicting rules. It should be possible to enable all rules without unavoidable conflicts. Furthermore, any setting on any rule (except for custom rules) should be able to coexist with any setting on any rule.

e.g., contrasted_opening_brace & opening_brace can't be enabled at the same time (at least under normal settings).

To resolve this, contrasted_opening_brace could be deprecated after the following options have been added to opening_brace:

• default_placement: same_line (current behavior), next_line (contrasted_opening_brace behavior).
• multiline_type_header_placement: same_line, next_line
• multiline_statement_condition_placement: same_line, next_line
• multiline_function_signature_placement: same_line, next_line

Also, the following rules could probably be merged:

• explicit_type_interface & redundant_type_annotation
• explicit_acl & explicit_top_level_acl
• …

Also, any rule should allow at least the enforcement of the opposite of the rule. Any rule whose requirements could be expressed based on an integer should also support any integer (possibly limited to non-negatives, or to positives).

e.g., explicit_enum_raw_value should have an option allow (or accept, …) with values always (default, current behavior) & only_when_necessary (requires that any explicit enum raw value be different than the default raw value for the case).

e.g., vertical_whitespace_between_cases forces one blank line. A non-negative integer line_count option would support the "opposite" of default (0 being no lines) or any number of lines (2 requiring 2 blank lines, etc.). See #6326 for the request for this, but the principle should be applied to all new rules, while existing rules should be retrofitted to support such options.

Also, any rule that depends on a specific string should have an option to configure the string.

e.g. prefixed_toplevel_constant requires a k prefix; that hard-coded value should be replaced by a prefix option that defaults to k to be compatible with the current behavior, but someone could change it to _, constant, etc.