RULE-5-10-1: fix false positives for locals/parameters in permitted std specializations (e.g. std::hash) - #1181

Description

RULE-5-10-1 ("User-defined identifiers shall have an appropriate form") reports
Identifier 'X' is defined in reserved namespace. for ordinary, well-formed,
snake_case local variables and function parameters — e.g. value, result,
view, identifier, instance_identifier, skeleton_instance_identifier —
whenever they are declared inside the body of an explicit template
specialization that C++ explicitly permits users to add to namespace std,
most commonly std::hash<UserType>::operator():

namespace std
{
template <>
struct hash<score::mw::com::impl::ServiceIdentifierType>
{
    size_t operator()(const score::mw::com::impl::ServiceIdentifierType& value) const noexcept
    //                                                                     ^^^^^ flagged: "Identifier 'value' is defined in reserved namespace."
    {
        return std::hash<std::string_view>{}(value.ToHashString());
    }
};
}  // namespace std

[namespace.std]/[hash.requirements] explicitly permit a program to add a
template specialization for a standard library template (like std::hash) to
namespace std, provided the specialization depends on a user-defined type.
value here is not a new member of namespace std in the sense the rule is
trying to prevent — it is an ordinary parameter name scoped to the function
body, which merely happens to be lexically nested inside namespace std { ... }
because that is where the standard requires the specialization to be written.

Change request type

• Release or process automation (GitHub workflows, internal scripts)
• Internal documentation
• External documentation
• Query files (.ql, .qll, .qls or unit tests)
• External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• No rules added
• Queries have been added for the following rules:
  • rule number here
• Queries have been modified for the following rules:
  • RULE-5-10-1

Release change checklist

A change note (development_handbook.md#change-notes) is required for any pull request which modifies:

• The structure or layout of the release artifacts.
• The evaluation performance (memory, execution time) of an existing query.
• The results of an existing query in any circumstance.

If you are only adding new rule queries, a change note is not required.

Author: Is a change note required?

• Yes
• No

🚨🚨🚨
Reviewer: Confirm that format of shared queries (not the .qll file, the
.ql file that imports it) is valid by running them within VS Code.

• Confirmed

Reviewer: Confirm that either a change note is not required or the change note is required and has been added.

• Confirmed

Query development review checklist

For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:

Author

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

Reviewer

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)