Include hashes of containing types when computing hash in EEClassHashTable

[VSadov]

Prior to this change all nested types with the same name would be placed into the same hash bucket, regardless of their enclosing types. That ensures collisions for common type names like Enumerator or <>c .

The approach in this change is similar to what we do in R2R hash - the hash function will now include hashes of enclosing types if such exist. The main difference from R2R approach is that we do this only for case-sensitive flavor of the table.
Case-insensitive table may be created as needed from case-sensitive prototype. Case-insensitive table by construction shares the encloser items with the prototype table and thus cannot use encloser hashes, since they would not be in the canonical casing.
That basically means the case-insensitive use stays on the same plan as before. It appears to be a relatively rare scenario to support some reflection features.

• some minor follow-ups to the changes in Completely lock-free ClassLoader::LookupTypeKey #61346

---

After measuring, the effects of the change appear to be fairly minor. It does reduce some collisions, but it is not a lot to start with and in case-insensitive case the collisions are still there, so we still have outliers.
I am not sure the result justifies the added complexity.

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[VSadov]

@jkotas - FYI, I have implemented this change to reduce hash collisions in EEClassHashTable, but decided that the results are not worth the added complexity.