refactor(codemod/biome_js_analyze): derive Applicability for all lint rule actions

[dyc3]

Summary

Following up on the previous PR, #2885, this changes all the JS rules to derive their applicability from the FixKind supplied in the metadata. Should completely resolve #2799.

closes #2799
closes #2797

Test Plan

Should compile and pass tests.

[codspeed-hq]

CodSpeed Performance Report

Merging #2889 will not alter performance

_{Comparing dyc3:05-16-refactor_codemod_biome_js_analyze_derive_applicability_for_all_lint_rule_actions (cd99dc8) with main (a678c68)}

Summary

✅ 99 untouched benchmarks

[dyc3]

To get the tests to pass, I had to change the fix_kind for these rules:

• useRegexLiterals
• useNumberNamespace
• noUnusedLabels
• noUselessLoneBlockStatements

All of these appeared to be emitting safe fixes before, so I've updated the fix_kind accordingly.

[Conaclos]

Should we implement Into<Applicability> for RuleMetadata? This could allow removing to_applicability() and just pass ctx.metadata(). If we keep to_applicability(), I suggest a distinct name: applicability().

[dyc3]

I don't think so. You're right in that it would reduce some of the boilerplate, but IMO it's inconsequential. To me, the From and Into traits represent an equivalence relationship between 2 types, and implementing Into<Applicability> violates that because it loses the majority of the information.

I do agree with the name change though.

[Conaclos]

Fair enough. Let's change the name and merge it :)

[ematipico]

Fair enough. Let's change the name and merge it :)

I suggested to_applicability because it follows rust naming conventions

[Conaclos]

I suggested to_applicability because it follows rust naming conventions

I suggested implementing into because the to_ misled me.
But this is not a conversion. So as_/to_/into_ doesn't apply here?
Moreover, according to the resource you point to, to_ indicates a costly operation. This is not the case here?

[ematipico]

Yeah it makes sense, now that I read more of the docs.

applicability() makes more sense