Summary

Closes #2912

This PR enables a new feature in the configuration, which is the possibility to opt-in the recommended rules suggested by the Rome team.

Configuration changes

It's possible to opt-in rules in two different way:

• Globally

{
	"linter": {
		"recommended": true
	}
}

• Group level

{
	"linter": {
		"rules": {
			"js" {
				"recommended": true
			},
			"jsx" {
				"recommended": false
			}
		}
	}
}

De-serialization of rules

While we desarialize rules, we also validate that the rules we have in the configuration rules are valid for the current group. If not, we emit a ConfigurationError. We do so by saving an array of all the rules that belong to a certain group.

The serialization is out of scope, because we don't have an use case yet. But the serialization will need to be custom, because we want to keep the order of the original map.

Code generation

All the new code (configuration shape, de-serialization and methods) are code generated from the metadata of the rules.

• all rules that belong to a group, are stored into an array
• the recommended rules are also stored into a const inside the struct, and they represented as an array of RuleFilter. The name of the rule is taken from Self::GROUP_RULES, so we don't repeat the static strings
• the struct Rules has now a method called as_analysis_filters which will emit two IndexSet of enabled filters and disabled. The reason why IndexSet was used is because the enabled filters needs to be computed from the difference with the disabled filters. Here's an example:

{
  "root": true,
  "linter": {
    "rules": {
        "recommended": true,
        "js": {
            "rules": {
                "noDebugger": "off"
            }
        }
    }
  }
}

In this example we need pull all the recommended rules, but then we have to remove the rules that have been turned off. IndexSet allows us to do so with a simple .difference function.

Computation of AnalysisFilter

Here's there have been some limitations, due to how RuleFilter is designed (all references), and because of that the creation of the AnalysisFilter object must be done in place, right before being used. This caused a bit of repetition of code. If you have a solution to avoid this repetition of code, it would be great

Test Plan

I updated some existing test and added new ones, some happy path and error path.