Rule Request: structured_function_doc requiring a short summary and a parameter list

New Issue Checklist

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

New rule request

Please describe the rule idea, format
this issue's title as Rule Request: [Rule Name] and describe:

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.

There is a structured way of documenting using markup and many use it in their code. It would be beneficial to enforce it and also check that the documentation matches the declaration.

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

Shouldn't trigger

/// This is a classic foo.
///  - Parameters:
///    - a: a parameter.
///    - b: b parameter.
///    - c: c parameter.
func foo(a: Type1, b: Type2, c: Type3)

/// This is a concise foo summary.
///
/// Here comes detailed discussion spanning lots and lots of lines.
///  - Parameters:
///    - a: a parameter.
///    - b: b parameter.
///    - c: c parameter.
func foo(a: Type1, b: Type2, c: Type3)

Should trigger

/// Foo doc is one parameter short.
///  - Parameters:
///    - a: a parameter.
///    - c: c parameter.
func foo(a: Type1, b: Type2, c: Type3)

/// Foo parameters are not in order.
///  - Parameters:
///    - c: c parameter.
///    - b: b parameter.
///    - a: a parameter.
func foo(a: Type1, b: Type2, c: Type3)

/// Too long summary taking
///  lots
///  and lots
///  and lots
///  and lots
///  and lots of lines.
///  - Parameters:
///    - a: a parameter.
///    - b: b parameter.
///    - c: c parameter.
func foo(a: Type1, b: Type2, c: Type3)

3. Should the rule be configurable, if so what parameters should be configurable?
   It should be configurable to enable user fine tuning it to a specific need and override any unnecessary inconveniences.

   • One should be able defining how long the short summary can be, including not limiting it at all.
   • minimal number of parameters should be configurable as one might treat it as unnecessary burden for functions with too few (1 for instance) parameters

4. Should the rule be opt-in or enabled by default? Why?
   Should be an opt-in, as it's a matter of personal style preference.

The issue names no implementation files or tests. Start by locating SwiftLint's existing documentation-comment rules and their tests, then compare the requested summary-length, parameter-count, and parameter-order checks with the examples. Done means an opt-in rule with the requested configuration options and coverage for the listed triggering and non-triggering cases.