Replace `no_grouping_extension` with `grouping_extension`

New Issue Checklist

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

Feature or Enhancement Proposal

Replace no_grouping_extension with grouping_extension with an allow (maybe choose a different name like accept) option with values:

• never: default, current behavior of no_grouping_extension
• always: require that anything that can be moved from a type declaration to an extension be in an extension

And a conformance_extension option that also accepts:

• default: allow if $allow == always; disallow if $allow == never (default)
• allow: allow extension for conformance to a protocol (allows conformances on extension; allows conformances on type if $allow == never)
• require: require extension for conformance to a protocol (allows conformances only on extension, not on type)

And a marker_conformance_extension option:

• default: mimics $conformance_extension (default)
• never: do not allow extension for conformance to a protocol without any members
• allow: allow extension for conformance to a protocol without any members (allows conformances on extension; allows conformances on type if $allow == never)
• require: require extension for conformance to a protocol without any members (allows conformances only on extension, not on type)

Maybe never should be the default for the above; if so, rename default as mimic_ conformance_extension.

And a conformance_extension_grouping option:

• single: default, only one conformance per extension
• multiple: allow multiple conformances per extension

(It doesn't make sense to me to allow some finite number of conformances per extension that is not 1, so I don't think that an integer value is appropriate here)

Maybe add an analyzer rule (I assume it can't be done in a non-analyzer rule) to require all members of a conformance extension to be relevant to the protocol, with an allow_helpers option that takes a visibility keyword or none (defaulting to private) to allow extension members besides those directly implementing a conformance to be included in the conformance, as long as they are not more visible than the given visibility.

Start by reviewing the existing no_grouping_extension rule and how SwiftLint exposes rule options. Clarify the defaults and interactions among grouping, conformance, marker-conformance, and conformance-grouping settings before implementation; done means the replacement behavior and analyzer-rule question have agreed semantics and coverage.