It is currently hard to tell what rule/rules are causing performance bottlenecks when using oxlint & JS plugins. This means it's tricky to know whether it is the linter's fault or the plugin/rules fault. This also makes triaging issue/regressions harder as we don't know exactly what's causing the slowdown.

To address this, we should introduce a --timings flag that records the timings for all rules.

In timing mode, we will run a different JS visitor path that can allow us to attribute time to individual JS plugin rules.

In scope:

• Timings for JS plugin rules
• Aggregated totals per rule (across all files)
• Human-readable CLI summary output when timing mode is enabled
• Low-overhead default path when timing mode is disabled

Out of scope:

• Rust/native rule timings (Adding these timings introduces a large performance hit (~15%)
• Per-file timing output

Current JS plugin execution compiles/merges visitors for performance, which makes direct per-rule timing in the normal hot path non-trivial.