Add a configurable Rubydex linter with rule discovery

[st0012]

Add an in-gem Rubydex::Linter framework and rdx lint [PATH] for running semantic rules against a workspace. The runner combines native and rule diagnostics, preserves related information, produces deterministic output, and fails only for error diagnostics.

The command discovers rules from the workspace and active Bundler dependencies, applies rubydex.toml settings, skips disabled rules, and warns about configured rules that were not loaded.

[soutaro]

It looks like RuleConfig isn’t consumed by the linter in this PR, and there doesn’t seem to be a standard way for a rule to access its configuration. Is that integration planned for a follow-up PR?

[st0012]

@soutaro Yes I split the work into multiple small PRs to speed up review

[st0012]

@soutaro I decided to expand a PR quite a bit so now config and automatic rule loading is part of the PR too.

[Morriar]

I wonder if someone will one day try to create a custom rule by subclassing another rule? 🤔

[st0012]

The linter in Core currently does this as well as we haven't seen a need to create abstract rule classes. I think we can design this later and finish the porting first. Will create an issue for this.

Issue: #984

[alexcrocha]

Both the rule discovery and config wiring look good to me 👍

I do have a question about merging the graph diagnostics with the rule diagnostics, mostly to shape my mental model on the concepts of linting rules and diagnostics. I know for the output they're both diagnostics, but are they the same concept that surfacing both through the linter is the natural output?

[st0012]

I think there's not a clear answer to it. But I think linter is where we should try surfacing them because:

• If you think about it, the graph diagnostics are the "rules" we made that we think the codebase should not follow.
• Among all the tools we've planned so far, linter is the only place that's suitable to surface them.

And if we found these diagnostics noisy later, we can:

• Review whether our diagnostics make sense at all. Perhaps we can remove some
• Provide a config to opt out

For now I'll keep them, but it'd be easy to drop as well.