Remove deprecated cli parameters --experimental, --code-style, --disabled-rules

[paul-dingemans]

Description

Remove deprecated cli parameters --experimental, --code-style, --disabled-rules

The .editorconfig is used for managing the configuration of ktlint regardless which API Consumer (for example Ktlint CLI, the KtLint intellij plugin, or third party integrators like Detekt, Spotless) is used. By using the .editorconfig, developers on the same project can use different tools to invoke ktlint, but the configuration is stored in 1 central place.

Ktlint CLI parameters --experimental, --code-style and --disabled-rules shadow .editorconfig properties, and should no longer be used. The parameters have been deprecated in a previous ktlint version (1.0), and so far only 1 request (#2397) to not remove them has been received.

The code style can be managed via .editorconfig property ktlint_code_style. See https://pinterest.github.io/ktlint/latest/rules/configuration-ktlint/

The disabled rules can be managed via .editorconfig properties. See:

• https://pinterest.github.io/ktlint/latest/rules/configuration-ktlint/#disabled-rules
• https://pinterest.github.io/ktlint/latest/faq/#how-do-i-enable-or-disable-a-rule-set
• https://pinterest.github.io/ktlint/latest/faq/#how-do-i-enable-or-disable-a-rule

Experimental rules can be managed via .editorconfig property ktlint_experimental. Also, it is possible via the .editorconfig to enable specific experimental rules. See:

• https://pinterest.github.io/ktlint/latest/rules/configuration-ktlint/#disabled-rules
• https://pinterest.github.io/ktlint/latest/faq/#how-do-i-enable-or-disable-a-rule-set
• https://pinterest.github.io/ktlint/latest/faq/#how-do-i-enable-or-disable-a-rule

Checklist

Before submitting the PR, please check following (checks which are not relevant may be ignored):

• Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
• At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
• Tests are added
• KtLint format has been applied on source code itself and violations are fixed
• PR title is short and clear (it is used as description in the release changelog)
• PR description added (background information)

Documentation is updated. See difference between snapshot and release documentation

• Snapshot documentation in case documentation is to be released together with a code change
• Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master