Logic to make linters robust to adversarial comments

[MichaelChirico]

Split of from #2899. Progress on #2737.

I tried to include here those linters that only fail under "adversarial" commenting, which is a bit subjective, the idea is to basically only consider cases of comments that are not particularly common in practice. In practice that means those listed in the NEWS on #2899 without an associated issue.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.25%. Comparing base (e67713d) to head (38d3220).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2901   +/-   ##
=======================================
  Coverage   99.24%   99.25%           
=======================================
  Files         129      129           
  Lines        7319     7335   +16     
=======================================
+ Hits         7264     7280   +16     
  Misses         55       55           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MichaelChirico]

Bumping :)

[Bisaloo]

As a general thought for the future: would it be terrible for performance to add a new xml_parsed_content_nocomments elements in the output of get_source_expression()? To avoid the gymnastics in each individual linter.

[MichaelChirico]

As a general thought for the future: would it be terrible for performance to add a new xml_parsed_content_nocomments elements in the output of get_source_expression()? To avoid the gymnastics in each individual linter.

True... also more awkward for downstream custom linter authors #2968