Split `oxc_linter` into multiple crates to improve compile time

The linter compile time has gotten pretty long now with the number of lint rules that we support. One idea I had to potentially improve compile time is to reduce the number of crates that need to be compiled and the number of crates that could be compiled in parallel.

This is just a rough idea, but I think we could potentially split this up into a few phases:

1. Phase 1: Split oxc_linter into oxc_linter_core and oxc_linter_rules.
   • oxc_linter_core contains essentially everything that isn't in oxc_linter/src/rules: config resolution, diagnostics, JS plugins, etc.
   • oxc_linter_rules contains all of the linter rules and generated code (rule runner impls, rule enum, etc.)
   • Once this phase is complete, we could at least re-compile oxc_linter_rules alone without needing to compile oxc_linter_core if you're making changes to lint rules locally. Unfortunately, you'd still need to compile both crates as oxc_linter_rules would depend on oxc_linter_core.
2. Phase 2: Split oxc_linter_rules into several plugin-based crates: oxc_linter_rules_eslint, oxc_linter_rules_react, etc.
   • This way if you're only developing a rule in a single plugin, you don't need to recompile all rules crates at once. And when doing a full recompile, all of the linter rules can be compiled in parallel instead of serially.

This would be a significant re-architecture of the crates. I'm not even entirely sure if it's possible. Just wanted to write this idea down somewhere durable though.

Start by mapping the existing oxc_linter crate, especially oxc_linter/src/rules, and identify how config resolution, diagnostics, JS plugins, rules, and generated code are organized. Then assess whether the proposed oxc_linter_core and oxc_linter_rules split is feasible, followed by the plugin-based split. Done means the re-architecture is validated and compile-time improvements are demonstrated.