Restructure ktlint parameters in ".editorconfig"

[paul-dingemans]

I would like to propose the way the settings of ktlint are organized in the ".editorconfig" file.

1. Prefix all ktlint specific properties with ktlint_ to make a clear distinction generic and intellij specific properties.
2. Replace property disable_rules with a setting per rule. Rules can be enabled and disabled explicitly. User are protected against new rules from the ruleset 'standard' being enabled when upgrading to new version. Also it allows user to enable specific rules from other rulesets.

ktlint_standard_filename_enabled = true
ktlint_standard_comment_spacing_enabled = false
ktlint_standard_max_line_length_enabled = true
ktlint_standard_max_line_length_max_length = 120
ktlint_experimental_multiline_if_else_enabled = true

This change requires other changes for best developer experience:

• Replace hyphens in rule-ids with underscores. This might not be needed if it is allowed to use hyphens in the ".editorconfig" keys.
• Report rules from standard ruleset for which the ktlint_standard_<rule-id>_enabled is not found so that user can choose explicitly whether to enabled or disable the rule.

[Tapchicoma]

Prefix all ktlint specific properties with ktlint_ to make a clear distinction generic and intellij specific properties.

I would agree with it, though currently it is only disabled_rules. Generally disabled_rules and ktlint_disabled_rules should be supported for some versions to make migration easier.

Replace property disable_rules with a setting per rule. Rules can be enabled and disabled explicitly. User are protected against new rules from the ruleset 'standard' being enabled when upgrading to new version. Also it allows user to enable specific rules from other rulesets.

See #548

[gabrielittner]

User are protected against new rules from the ruleset 'standard' being enabled when upgrading to new version. Also it allows user to enable specific rules from other rulesets.

I don't think having to maintain a list of all standard rules in each project to just run the standard rules is something that scales well. If it's a standard rules it should like the name says be the standard, so on/true by default.

The suggestion of individual properties still sounds like a good idea for disabling standard rules though. It is also a much better experience for experimental rules than the current enable all experimental rules with a flag and the disable those again that you don't want.