[FEATURE] Exclude field from hashCode but not from equals

[Wolowin]

Describe the feature
Implement a parameter excludeFromHashCodeOnly for @EqualsAndHashCode class annotation
and/or
@EqualsAndHashCode.ExcludeFromHashCodeOnly field annotation

The behavior that I expect would be the same as of parameter "exclude" but it would only take effect on hashCode. This shouldn't break the contract that Java imposes in regards to equals and hashCode. If we only exclude some fields from hashCode but dont include any new ones, the hash will still be the same when equals returns true, which is required by the contract.

I will skip the part with providing java samples, as I think the similarity to already existing exclude parameter makes it pretty clear

Describe the target audience
Why is this useful?

1. You want a hashCode hat would exclude some fields to calculate hash for your business logic, but dont wanna change equals for various reasons (for example when inserting into sets / maps)
2. You want to improve performance, which can be achieved by removing some complex fields from hashCode, but definitely you want them in equals for the final equality checks.
3. You need to exclude new class fields from hashCode, because you stored the hashCodes somewhere in database and need a comparison against the old hashCodes after the object changes.

[janrieke]

From a functional perspective you could do that without violating the contract. However, I don't think that's a good idea, also regarding the described use cases.

1. Such an approach could severely degrade the performance of hash-based data structures, because they rely on hash codes that are as distinct as possible. If you really need a specific hash code for your business logic, you should implement it in a different method.
2. Lombok supports caching for hashCode, so performance should not be a big issue. Especially when there are complex equality checks, having more hash code collisions could degrade performance much more than expensive hashCode calculations.
3. You should not rely on the consistency of hashCode, because its contract explicitly says:

This integer need not remain consistent from one execution of an application to another execution of the same application.