Implement --extend-fixable option

[charliermarsh]

Summary

This PR adds an --extend-fixable command-line and configuration file option, and changes the semantics to match those of --select (i.e., providing a new --select wipes out previous ignores, and so on).

Closes #4289.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

[MichaReiser]

My concern with adding --extend-fixable, or any other new CLI argument that directly match to a configuration option is that we ultimately end up with a whole lot of CLI arguments: One to override every option in the configuration. What do you think of adding a --config [key1=value1,key2=value2,...] option that allows specifying ANY option in the configuration similar to rustfmt or clippy?

[charliermarsh]

I'm generally open to something like that, though I think in this case, it does make sense to add --extend-fixable, since it's an inconsistency in the API:

Rule selection:
      --select <RULE_CODE>
          Comma-separated list of rule codes to enable (or ALL, to enable all rules)
      --ignore <RULE_CODE>
          Comma-separated list of rule codes to disable
      --extend-select <RULE_CODE>
          Like --select, but adds additional rule codes on top of the selected ones
      --per-file-ignores <PER_FILE_IGNORES>
          List of mappings from file pattern to code to exclude
      --fixable <RULE_CODE>
          List of rule codes to treat as eligible for autofix. Only applicable when autofix itself is enabled (e.g., via `--fix`)
      --unfixable <RULE_CODE>
          List of rule codes to treat as ineligible for autofix. Only applicable when autofix itself is enabled (e.g., via `--fix`)

(Notice that --extend-select exists, but not --extend-fixable.)

[MichaReiser]

I'm generally open to something like that, though I think in this case, it does make sense to add --extend-fixable, since it's an inconsistency in the API:

What is your suggestion to decide on when we should add new explicit options? Should we also add extend-ignore, extend-per-file-ignores, and extend-unfixable? That's why I think I would prefer to potentially decide on adding support for --config (and rename the existing --config option to --config-path?) because I fear that it will always be possible to reason that some option should be supported because we already support some other option.

[charliermarsh]

I think we should add these for all of the rule selection APIs, but not for the rule configuration APIs. That's my general stance right now.