[Feature] Add support for overriding rules

[kthatipally]

We're requesting the addition of a feature that would allow us to override rules within downstream repositories, similar to the functionality provided by Windup (https://github.com/windup/windup-rulesets/tree/master/rules/rules-overridden-azure).
This capability will enable us to tailor rules to specific targets and messages, thus enhancing the flexibility and adaptability.
The ability to customize messages based on different targets would be particularly valuable.

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[shawn-hurley]

IIUC the use case, Ruleset A wants to use all the rules from Ruleset B and then wants to selectively override specific outputs and then for the output to look like a single ruleset was run.

Hopefully, that is correct, but if it is incorrect, then ignore the rest of this, and we can chat about the misunderstanding of the use case!

As we move into the multiple providers, I think a ruleset should be stand-alone, and intra-rule dependencies should not be something that we add. More specifically, If you are running Ruleset A, you will get the output for Ruleset A. Ruleset A's output should not be able to interfere with Ruleset B's output.

I have two questions that I think we need to answer before starting down this path and designing intra-rule dependencies.

1. Why can't both output exist's.
2. If you want to re-use a ruleset and apply changes, why isn't a fork and re-name of that ruleset sufficient?