Fix TypedKey equals/hashCode symmetry with Key

[gunjanjaswal]

Summary

Fixes #13678.

TypedKeyImpl is a record implementing Key, but it never overrides equals/hashCode, so Java generates them from both record components and only matches another TypedKeyImpl. Adventure's KeyImpl.equals compares any Key by namespace + value, so equality is one-directional:

Key key = Key.key("minecraft:stone");
TypedKey<ItemType> typedKey = TypedKey.create(RegistryKey.ITEM, key);
key.equals(typedKey);   // true
typedKey.equals(key);   // false

That breaks the symmetry clause of Object.equals, and the two hash differently, so a TypedKey can go missing in a HashSet<Key> built from plain keys, and contains/remove turn order dependent when both types are mixed.

This overrides equals/hashCode on TypedKeyImpl:

• Against another TypedKey, compare underlying key and registry key (same as before, so keys from different registries stay distinct).
• Against a plain Key, compare namespace + value to match adventure and stay symmetric.
• hashCode returns the underlying key's hash so equal keys share a hash.

One tradeoff: a TypedKey now equals its plain Key, so two TypedKeys with the same key but different registries stay unequal while both equal that plain key, which can break transitivity in that mixed case. That is inherent to TypedKey extends Key (Effective Java item 10). This follows the approach suggested in the issue; if you'd rather have strict transitivity, I can make equality key-only instead.

Changes

• TypedKeyImpl: override equals/hashCode.
• Add TypedKeyEqualityTest covering symmetry, hashCode consistency, and registry distinction.

[Lulu13022002]

I'm strongly against this, TypedKey should just not extends Key, Keyed maybe at best.

[lynxplay]

Agree with Lulu. It is a bit nasty, a typed key should be able to extend Key, it is identifying something via a namespace and value but the fact that a the plain key implementation considers any key with equal namespace and value equal means we should probably bite the bullet and make this keyed instead. A pretty meh equal impl of KeyImpl imo, idk if this is worth bringing up with adventure folks.

[gunjanjaswal]

Makes sense, thanks both. Agree that having TypedKey extend Keyed rather than Key is the cleaner fix instead of patching equals. That's a breaking API change and a call for you all (and possibly the adventure folks), so I'll close this and leave #13678 for that direction. Appreciate the look.