Hash code updates.

[PaulSandoz]

This pull request contains a number of updates related to the hash code of sets and maps primarily to enable the removal of HollowObjectHashCodeFinder and related hash code functionality at least on the producer side and limited use on the client side (specifically to ensure efficient lookup of elements or keys when using HollowSet or HollowMap until a solution is implemented that can reliably extract a hash key from an object).

• Support @HollowHashKey and hash key with empty fields for hollow set and map schema. This feature can override the application of a default hash key (see HollowObjectMapper.useDefaultHashKeys which is true by default) when it is required that ordinals be used as the hash code.

• Allow a consumer to filter out hash keys of set or map schema. The consumer needs to register an instance of HollowObjectHashCodeFinder whose method getTypesWithDefinedHashCodes returns a Set that contains the element or key type of the set or map schema. This is a breaking change for an edge case: prior to this change a set/map with a hash key would override that of HollowObjectHashCodeFinder. However, prior to this change it was not expected that a consumer implement getTypesWithDefinedHashCodes with anything but an empty set.

• Ensure a map or set whose element or key type is filtered (or not present) can still be processed. Any hash key is ignored since the field paths cannot be resolved.

• When performing a checksum calculation for a set or map relax the schema equality check for the hash keys if the schema evolved from no hash key to with a hash key. This enables a transition from no hash key (the hash is defined externally using HollowObjectHashCodeFinder) to a hash key (the hash is defined by the hash key on the schema).

• Ensure a producer can transition (with restoration) from a state where HollowObjectHashCodeFinder was used (and where default hash keys were not enabled) to generate hash codes to where HollowObjectHashCodeFinder is not used (and where where default hash keys are enabled). If hash codes are the same in both cases then the checksum calculation performed in the integrity check stage should not fail.

[PaulSandoz]

I pushed another commit that:

• fixes the bug for schema mismatch when applying a checking; and
• simplifies the field path array argument processing for set and map schema when constructed to explicitly use the ordinal as the hash code.