[RFC] Add strict config(s) for optioned rules

[ShGKme]

Problem

Some rules are simple:

• Don't require semantic changes (e.g. renaming a variable or changing declaration context)
• Always work well (e.g. trailing comma never hurts)
• Can be auto-fixed

However, some rules are problematic to apply:

• Require semantic changes
• Make readability worth in some cases
• Require significant manual changes (e.g. rewriting component to TS or renaming components)
• Can be auto-fixed, but with LARGE changes
• Or just too discussable

Examples:

• Shadowing:
  • fix(typescript): remove @typescript-eslint/no-shadow #993
• Single-line arrays/objects:
  • fix(codeStyle): allow devs write small objects in one line #996
  • fix(codeStyle): allow single line arrays #997
• Top-level function style
  • [RFC] Top-level function style #1003
• TS-first rules in a mixed environment
  • Types are removed from JSDoc in .vue when there it has no lang="ts" #980
  • fix(vue): allow JS Vue files #998
• Forced <script setup lang="ts">
• Forced <script> - <template> - <style> order in components
• Forced multi-word component naming
• Following Vue style guide to have first attribute on a new line (diff safe)

Proposal

Instead of hot discussions, local rule overrides and avoiding "painful" rules, we can provide them in a additional config

[susnux]

Instead of hot discussions, local rule overrides and avoiding "painful" rules, we can provide them in a additional config

I would say:
Either we care about the rules or we do not. The config should enforce the best case, if an app e.g. does not fulfill it it can exclude the rules until fixed.

Meaning we should have a consens about code style and code quality and thus decide how the code should look like.
If the rule provides autofixing than it could be always added, if not we should add those rule only with warning severity so you can ignore them until some time.

But we should not add configuration with different rules based on painfulness or taste, we should only separate configs for use cases (Vue2 vs Vue3 / Library vs App) so we share the same rules in general.