Summary

Closes #2946

This PR adds new code generated methods to compute the Severity based on the configuration of the rule. This allows to inspect it and decide of the Diagnostic emitted by the linting phase should be changed.

The change of severity is done at Workspace level. This should have an added benefit to be language-agnostic and to work on different clients (CLI and LSP).

Architectural changes

The severity of the diagnostics is now computed by workspace, this means that when creating a rule, we won't be able to decide there the severity of rule.

The golden rule is the following:

• if the rule is recommended, by default it will emit and error;
• if the rule is not recommended, by default it will emit a warning;

In order to achieve that, I created a new data structure AnalyzerDiagnostic (suggested by Leo) which is simply a middle man that holds all the information to create a fully fledged Diagnostic, but it doesn't have the severity. When calling into_diagnostic, a severity must be passed and it will emit a Diagnostic. into_diagnostic is called by the workspace when requesting the diagnostics of a file.

In order to correctly build the documentation of the rules, the codegen now creates a slim workspace and via WorkspaceExt we are now able to compute the correct severity of the diagnostics.

Fixes

This PR also fixes a bug where the recommeded rules were incorrectly computed in some cases.

The rule useSemplifiedLogicExpression is not recommended anymore because of #2948

Pending works

This change unlocks something really interesting for our adoption. Now that a workspace is needed to compute these diagnostics correctly, the playground is now is not able to correctly compute this information.

In fact, the PR changes also the playground crate. When computing the diagnostic (via signal.diagnostic()), we default to Severity::Error. This is correct for now because the playground only runs the recommended rules, which will emit errors by design. Once the playground will be able to tweak the configuration of rules, then we will need to create a workspace instance just for the playground.

Test Plan

Created new test cases.

I also manually checked the LSP.

Given the following configuration:

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "js": {
        "rules": {
          "noDeadCode": "error"
        }
      }
    }
  }
}

notice that noDeadCode is an error.

Instead, given the following configuration:

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "js": {
        "rules": {
          "noDeadCode": "warn"
        }
      }
    }
  }
}

Notice now how the LSP shows a warning instead.

Updated documentation for the website and the snapshot tests.