Improve hash implementations for immutable objects.

[mvanaken]

Some hash implementations in Metal are expensive and we should improve that to boost performance of Metal.

The general contract (JavaDoc) of hashCode() states:

1. Whenever it is invoked on the same object more than once during an execution of a Java application, hashCode() must consistently return the same value, provided no information used in equals comparisons on the object is modified. This value doesn’t need to stay consistent from one execution of an application to another execution of the same application.
2. If two objects are equal according to the equals(Object) method, calling the hashCode() method on each of the two objects must produce the same value.
3. It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables. As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.

In addition, see e.g. University of California, Berkeley, a good hash function meets the following criteria:

4. All objects that are .equals, must have the same hashCode. => equal to contract criteria 2
5. hashCode values should be spread as evenly as possible over all ints.
6. hashCode should be relatively quick to compute.
7. hashCode must be deterministic (not random). => equal to contract criteria 1

Criteria 1 and 7 are equal, criteria 2 and 4 are equal, and criteria 5 is met by using the Object.hash() method as much as possible which helps to spread the hashcodes evenly.

So, to implement good hash codes, we should consider the following simplified criteria:

• hashCode must be deterministic (not random).
• All objects that are .equals, must have the same hashCode.
• It is not required that if two objects are unequal, the hashCode is unequal.
• hashCode should be relatively quick to compute.

All of the hash function implementations within metal meet these criteria, except for the last. Not all hashCodes are quick to compute.
The DataExpressionSource calculates the hash of the whole parseState it is dependent on and this source is created when using Ties in your tokens.
When Values from a Tie of a large parsegraph are placed within a hashmap, this may cause a significant performance drop.

There are multiple solutions possible:

• Simplify the hash implementation for ParseState (and possible others), e.g. not taking the whole objects into account, but only the sizes, for the lists and the graph. You might say that if all of the graphs and lists are of the same size and the offset is the same, it is very rare to be in a different state. This may cause hash collisions for two objects that are actually not equal, but since it is not required for two unequal objects to have unequal hashCodes and we are talking about very rare possibilities, this drawback does not weigh the criteria of "quick to compute".
• Cache the hash for all immutable objects. Since they will never change, it is sufficient to calculate it once.

There is not neccessarily a choice between these solutions. We can actually implement them both.