Fix the query hashing algorithm

[Geal]

This splits part of the work from #5255 to make it easier to merge. This PR only covers the fixes for the query hashing algorithm, which is currently used in entity caching, without integrating the changes to the query planner cache key.

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Tests added and passing³
  • Unit Tests
  • Integration Tests
  • Manual Tests

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[Geal]

@IvanGoncharov I added the initial support for the context directives. I will take another look tomorrow, but I think the approach is sound:

• as we go through the query, whenever we encounter a @context directive, we record the type in a map context name -> [Type}
• when we encounter a field with the join__field directive and its contextArguments argument, then for each argument, we take the context name and selection
• we look up the types linked to that context name. Considering the way we go through the query and relevant types, it might return types that would not appear in this query, so it might be a bit stricter than necessary
• for each of those type, we then use the selection and hash that in the same way we handle @key and @requires

There are some assumptions in there that we might want to check, like what happens when a contextArgument refers to a context that we did not find in the query (maybe that would have been prevented at composition?)

[IvanGoncharov]

Converting to draft as result of internal discussion regarding the risks introduced by parent PR, see details in #5255