feat(linter): implement useImportExtensions

[minht11]

Summary

Closes #2674
Implements import/extensions requirement for relative extensions.

Rule suggests unsafe fix based on current file and import path, given the limitations of not being able to access file system.

Test Plan

Added snapshots

[codspeed-hq]

CodSpeed Performance Report

Merging #2725 will not alter performance

_{Comparing minht11:feat/useImportExtensions (9a5a6d6) with main (9a05b77)}

Summary

✅ 92 untouched benchmarks

[vohoanglong0107]

Should we disable this rule for typescript files? For a typical typescript projects, adding files extensions is usually handled by the bundler, and typescript doesn't even allow imported files to end with .ts or .tsx

[minht11]

@vohoanglong0107 As of typescript 5.0 you can use .ts extensions, this rule would not have much use otherwise. I don't see case where user would want to enable .js extensions, but not .ts

[arendjr]

Nice rule!

Just a performance nit.

[ematipico]

Overall it looks good. There are few missing cases, and left few suggestions to avoid allocations

[ematipico]

The rule doesn't cover import("./file.js") and require("./file.js"). @minht11, do you plan to add it to this PR or a following PR?

[Conaclos]

Once the conflicts resolved, I think we can merge this PR.

[minht11]

@Conaclos what about windows tests? Right now they fail, because on windows os paths us different slash. Should I replace pathBuf with vector or something like that?

[ematipico]

@Conaclos what about windows tests? Right now they fail, because on windows os paths us different slash. Should I replace pathBuf with vector or something like that?

We shouldn't rely on PathBuf to compose the new imports. Instead, we should do that manually.

[ematipico]

I am going to block it until we fix Windows test cases.

We should compose the new import specifier manually instead of using PathBuf.

[arendjr]

Ah, I've also run into that at some point. Maybe we should add it to the contributing guide somewhere. Path is usually better for inspecting path-like strings, but plain String is better for building paths (at least for our use cases) if you don't want to run into surprises on Windows.

[minht11]

I replaced path_buf with string concatenation, windows test now pass.

[ematipico]

The documentation doesn't mention whether it supports import() and require() or not, we should add that

[ematipico]

Suggested change

	/// Require import extensions for relative imports.
	/// Enforce file extensions for relative imports.

[ematipico]

Suggested change

	/// enforces the use of import extensions for relative imports to make the code more consistent.
	/// enforces the use of file extensions for relative imports to make the code more consistent.

[ematipico]

Suggested change

	/// Tooling also benefits from explicit import extensions, because they do not need to guess which
	/// Tooling also benefits from explicit file extensions, because they do not need to guess which