feat: add (opt-in ember-template-lint parity) template-lint-migration config

[johanrd]

Summary

Adds eslint-plugin-ember/configs/template-lint-migration' — an opt-in flat config that enables the same ~94 template rules as ember-template-lint's recommended preset, making it straightforward to drop ember-template-lint and keep equivalent coverage.

import eslintPluginEmberRecommended from 'eslint-plugin-ember/configs/recommended';
import eslintPluginEmberTemplateLintMigration from 'eslint-plugin-ember/configs/template-lint-migration'';

export default [
  ...eslintPluginEmberRecommended,
  ...eslintPluginEmberTemplateLintMigration,
  {
    rules: {
      // migrate overrides from .template-lintrc.*
      'ember/template-no-bare-strings': ['error', { allowlist: ['×'] }],
      'ember/template-no-inline-styles': 'off',
    },
  },
];

Why not part of recommended?

Template linting is a separate concern from Ember JS linting, and many projects will want to adopt it incrementally or tune individual rules (e.g. no-bare-strings allowlists, no-inline-styles) before committing to the full set. Keeping it opt-in avoids a breaking change and lets teams migrate at their own pace.

Why no gjs/gts overrides?

ember-template-lint's recommended config disables several rules for .gjs/.gts files (no-curly-component-invocation, no-implicit-this, builtin-component-arguments, no-builtin-form-components, no-unknown-arguments-for-builtin-components) because template-lint has no JS scope tracker and can't distinguish a JS-scoped binding from an implicit-this lookup inside <template>.

The ported rules in this plugin don't have that limitation:

• no-implicit-this and no-curly-component-invocation walk ESLint's scope chain and skip any identifier that resolves to a JS binding (import, const, param, block param).
• no-builtin-form-components explicitly checks filename.endsWith('.gjs/.gts') and only flags components imported from @ember/component.
• no-unknown-arguments-for-builtin-components checks whether a tag is shadowed by a JS-scope variable before flagging.

Adding the overrides would suppress correct behaviour in gjs/gts, not fix a real problem.