Extended matching for `inclusive_language` rule and possible `disallowed_terminology` rule

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Description

I wasn't sure whether it would be more appropriate to add a comment to #3243 or to make a new issue since it's slightly unrelated, but:

Has there been any discussion about adding checks for comments, strings, etc. for the inclusive_language rule, or has there been any more discussion about adding a more general rule for disallowed terminology (like the one suggested in #3243) that would exist alongside the inclusive_language rule?

I have a list of more general terms that I'd like to look for throughout the code. The functionality that the inclusive_language rule has is exactly what I want, but it appears that it only checks identifiers, and the use-case is specialized. Even if I wanted to only match identifiers and added to the additional_terms array in the inclusive_language rule, some of the words that could be disallowed aren't related to inclusivity and might lead to confusion about what the error is actually about.

Thanks!

Start by reviewing the existing inclusive_language rule and the related discussion in #3243. Clarify whether matching should include comments and strings, and whether general disallowed terminology belongs in a separate rule; the work is done when the scope and expected diagnostics are agreed and implemented.