Chore: Adopt eslint-plugin/prefer-message-ids rule internally

[bmish]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[X] Other, please explain:

What changes did you make? (Give an overview)

The public rule eslint-plugin/prefer-message-ids is more robust than our internal version, and it's also valuable for us to dogfood this public rule as it's the same one that third-party plugin authors will use. So this PR deletes our custom version and switches us to the public rule for internal usage.

Follow-up to #14823.

CC: @aladdin-add

Is there anything you'd like reviewers to focus on?

No.

[aladdin-add]

👍

[mdjermanovic]

It makes sense to enable eslint-plugin/prefer-message-ids, as it catches some things that internal-rules/consistent-meta-messages doesn't (e.g., someone could define meta.messages but still mistakenly use message in context.report()).

However, it doesn't work for rules where context is passed to functions that eventually call context.report(), like no-duplicate-imports or padding-lines-between-statements, so maybe we should use both the plugin rule and the internal rule?

[bmish]

It is true that we can't always detect all usages of context.report since it may be used inside helper functions. If we're worried about that, how about I update eslint-plugin/prefer-message-ids to also flag a violation when meta.messages is missing? That's a new rule I just wrote and I would much prefer to have one comprehensive rule (covering both situations) rather than rely on two.

UPDATE: fix in eslint-community/eslint-plugin-eslint-plugin#173.

[mdjermanovic]

If we're worried about that, how about I update eslint-plugin/prefer-message-ids to also flag a violation when meta.messages is missing? That's a new rule I just wrote and I would much prefer to have one comprehensive rule (covering both situations) rather than rely on two.

Makes sense to me 👍

[bmish]

@mdjermanovic I have updated the rule to handle that case so this PR is ready to be merged :)