[request] Add capability to configure in-code instead of YAML

[Starlight220]

This could be used primarily for integration with spotless.

[petertrr]

Hi @Starlight220 , thanks for your feedback! What exactly do you mean by in-code configuration? Diktat already has an integration with spotless, which accepts yaml configuration. What is your use case for programmatic alternative?

[Starlight220]

Instead of splitting the configuration to the YAML file, having all the format config in one place (the gradle script) would be nice. From the user side, it would either be a map (similar to userData in the ktlint Spotless integration) or properties (which can be backed by the map in the impl).

For configuring of a lot of inspections a separate config file would be better, but in cases where only a few inspections are configured, it'll be much more efficient.

Is this a wanted feature?

[orchestr7]

@Starlight220 several notes about configuration:

1. I would actually like to support TOML configuration format together with YAML. So diktat would check which one is provided.
2. your idea sounds very interesting, but is difficult to implement as we would need to support these configurations (we have many of them) in a gradle config.

I think we should focus on this task, but with a medium priority

[orchestr7]

Actually we even have a special generated class called WarningNames.kt. It contains all generated names of warnings.
We can use it to cover this scenario.

In gradle plugin we would have something like this:

config {
    WarningNames.PACKAGE_NAME_MISSING {
        enabled = false,        
    }
}

[nulls]

it's duplicated by #1694