fix: provide unique fix and fix.range objects in lint messages

[mdjermanovic]

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
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Fixes #16716

What changes did you make? (Give an overview)

Updated report-translator to always create new fix objects and fix.range arrays. This ensures that lint messages do not share same instances, which could be problematic for processors that mutate these objects.

Added unit tests for report-translator, and one higher-level linter test that specifically targets the case described in #16716.

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

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	d82e6f0
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/64a44c7fb930a0000736a25e

[fasttime]

Thanks for this PR. I think that a processor postprocess() function can still return objects with non-unique references, so if problems are passed from a processor to the next one, there is still a chance that some of them will have identical fix and fix.range?

[mdjermanovic]

I think that a processor postprocess() function can still return objects with non-unique references, so if problems are passed from a processor to the next one, there is still a chance that some of them will have identical fix and fix.range?

That looks like something that should rather be fixed in the processor? I think it's unlikely that "normal" processing of messages with unique references produces an output with shared references.

[fasttime]

LGTM!

[nzakas]

LGTM. Just left one suggestion to clarify JSDoc, but otherwise, ready to merge.