feat(linter): implement noRestrictedTypes

[minht11]

Summary

Closes #3583 Rule allows user to specify types which they want to prevent used in their code. Similar to noRestrictedGlobals and noRestrictedImports

Test Plan

Added snapshots

[codspeed-hq]

CodSpeed Performance Report

Merging #3585 will degrade performances by 6.22%

_{Comparing minht11:feat/no-banned-types-options (efaad79) with main (73656ec)}

Summary

❌ 1 regressions
✅ 98 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	minht11:feat/no-banned-types-options	Change
❌	pure_9395922602181450299.css[cached]	3.5 ms	3.7 ms	-6.22%

[dyc3]

Why can't we just add user options to the old rule with defaults that keep the behavior the same? Is a new rule really necessary?

[minht11]

I think the idea is that we need to rename the rule to be more consistent with other rules noRestrictedImports, noRestrictedGlobals and now noBannedTypes noRestrictedTypes, ts-eslint also renamed theirs. Adding the new rule allows users to migrate incrementally while we deprecate old one.

[Conaclos]

I think that we should follow the lead of TypeScript ESLint that decided to split no-banned-types into several rules. For now, we could keep noBannedTypes to ban types like Boolean, and we could dedicate noReswtrictedTypes to user-defined types. This will simplify the rule impl and make it more consistent with other noRstricted* rules.

[Conaclos]

We could make the message optional and generate a default message such as Use <fix_with> type instead.
Also, I could rename fix_with with use.

Suggested change

	message: String,
	fix_with: Option<String>,
	message: Option<String>,
	use: Option<String>,

We could add a validation state that ensures that use is a valid identifier (a function js_ident allows checking it) and at least one field is specified (either message, or use, or both).

[minht11]

I renamed the field, not sure about making message field optional, banning types should be very intentional action and default explanation would not be helpful for other people.

I would like to make option to accept string directly like this

type Options = {
  foo: string | { message: string }
}

Though I am not sure how to do that with Serde

[ematipico]

@minht11 do you need any help to land this PR?

[minht11]

@ematipico Sorry been bit distracted, will fix up this PR this week.

[minht11]

I think that we should follow the lead of TypeScript ESLint that decided to split no-banned-types into several rules. For now, we could keep noBannedTypes to ban types like Boolean, and we could dedicate noReswtrictedTypes to user-defined types. This will simplify the rule impl and make it more consistent with other noRstricted* rules.

It does make sense. Looking into typescript-eslint 8 docs now I see they made this rule only for custom types, when I originally implemented this rule I was referencing ts-eslint 7.

I will remove default banned types and leave that functionality for noBannedTypes instead. It is consistent with noRestrictedGlobals and noRestrictedImports

[Conaclos]

Looks good to me. I left last suggestions. Once addressed we can merge 🚀