ruff 0.0.287

Using the location in the code file as part of the hashing for the fingerprint causes a comparison between reports to show one issue as fixed, and a new one as having come to, if other parts of a file is changed, causing the line number to change.

As a comparison, this is how eslint-gitlab-reports calculate hashing: https://gitlab.com/remcohaszing/eslint-formatter-gitlab/-/blob/main/index.js?ref_type=heads#L72

In its (ruff) current for, the output in gitlab will show a lot of noise when reporting on code quality if, say, a line is inserted above all the linting issues in a code file, and moving them one line down. They will all get new fingerprints, and the fingerprints that were in the old report will be gone.