refactor(rules): migrate all Rule impls to define_rule! macro

[gvozdvmozgu]

No description provided.

[gvozdvmozgu]

@benfdking it seems much simpler, and in the future it will be easier if we want to remove the Rule trait.

[github-actions]

Benchmark for 904116d

Click to view benchmark

Test	Base	PR	%
DepthMap::from_parent	39.9±0.35µs	40.4±0.40µs	+1.25%
fix_complex_query	9.3±0.18ms	9.8±0.67ms	+5.38%
fix_superlong	102.5±5.61ms	108.2±7.92ms	+5.56%
parse_complex_query	2.9±0.03µs	2.8±0.05µs	-3.45%
parse_expression_recursion	5.1±0.11µs	5.1±0.04µs	0.00%
parse_simple_query	802.7±9.88ns	799.6±9.03ns	-0.39%

[benfdking]

Hey 👋

This to me feels somewhat simpler and more complex in the same breath: Cleaner as the rule code itself looker simpler, less approachable because of that macro.

I honestly don't know which is better, so happy to go with your recommendation.

As I see it at the moment, there's a neat win in having rule descriptions also apply in Rust docs. Curious to understand though why you think we can drop the trait/why we would want that.

[gvozdvmozgu]

By removing the Rule trait, we avoid cloning the rule when generating linter warnings (i.e., cloning the entire struct, not just a pointer, which can be costly if the rule carries configuration) and can finally eliminate the dyn_clone dependency.

[gvozdvmozgu]

However, this will probably also require modifying the configurator, as suggested in an issue, to consolidate everything into a single large Config struct.

[benfdking]

By removing the Rule trait, we avoid cloning the rule when generating linter warnings (i.e., cloning the entire struct, not just a pointer, which can be costly if the rule carries configuration) and can finally eliminate the dyn_clone dependency.

Happy to give it a go for the above.

[github-actions]

Benchmark for cabd0ba

Click to view benchmark

Test	Base	PR	%
DepthMap::from_parent	61.2±0.83µs	60.2±1.75µs	-1.63%
fix_complex_query	12.1±0.16ms	12.1±0.41ms	0.00%
fix_superlong	140.8±7.00ms	134.7±7.49ms	-4.33%
parse_complex_query	4.1±0.04µs	4.1±0.05µs	0.00%
parse_expression_recursion	7.2±0.10µs	7.3±0.24µs	+1.39%
parse_simple_query	1058.0±13.51ns	1092.1±38.29ns	+3.22%