Make property changes more robust

[SirYwell]

Overview

Fixes #2961

Description

Different block types can share a property with the same name but with different types. In such case, we shouldn't try to apply the property with invalid values.

We could probably also remove the IllegalArgumentException and just return the current block state instead in BlockState#with(PropertyKey,V), but that might hide other problems. Thoughts?

### Submitter Checklist
- [x] Make sure you are opening from a topic branch (**/feature/fix/docs/ branch** (right side)) and not your main branch.
- [x] Ensure that the pull request title represents the desired changelog entry.
- [x] New public fields and methods are annotated with `@since TODO`.
- [x] I read and followed the [contribution guidelines](https://github.com/IntellectualSites/.github/blob/main/CONTRIBUTING.md).

[dordsor21]

We should keep the exception, else we're just silently failing. No failure implies it should have "worked"

[dordsor21]

Does this definitely make sense to have? If the key ID is dynamic to the original block state, that may not work, and if it's global that wouldn't work either?

[SirYwell]

Our PropertyKey and its ID are unique, so they are at the same position in each propertiesMapArr. But the actual property class stored there can have different types in different arrays.

[dordsor21]

Okay cool, so just a quick and dirty check so we don't need to check further

[SirYwell]

We should keep the exception, else we're just silently failing. No failure implies it should have "worked"

Probably worth to note that the default impl of Property#getIndex(T) doesn't fail when passing incompatible types, but overridden methods will throw a CCE. That's also why fence -> wall doesn't throw in the related issue, but wall -> fence does.

[dordsor21]

We should keep the exception, else we're just silently failing. No failure implies it should have "worked"

Probably worth to note that the default impl of Property#getIndex(T) doesn't fail when passing incompatible types, but overridden methods will throw a CCE. That's also why fence -> wall doesn't throw in the related issue, but wall -> fence does.

I think I'm looking at the wrong getIndex method - it seems like it returns -1 on failure? in all overrides?

[SirYwell]

I think I'm looking at the wrong getIndex method - it seems like it returns -1 on failure? in all overrides?

E.g.

FastAsyncWorldEdit/worldedit-core/src/main/java/com/sk89q/worldedit/registry/state/BooleanProperty.java

Lines 39 to 42 in 8c01959

	@Override
	public int getIndex(Boolean value) {
	return value ? defaultIndex : 1 - defaultIndex;
	}

only accepts Boolean arguments. The compiler adds a synthetic bridge method getIndex(Object) that basically just delegates but with a cast. That's where we fail then.

[dordsor21]

E.g.

FastAsyncWorldEdit/worldedit-core/src/main/java/com/sk89q/worldedit/registry/state/BooleanProperty.java

Lines 39 to 42 in 8c01959

	@Override
	public int getIndex(Boolean value) {
	return value ? defaultIndex : 1 - defaultIndex;
	}

only accepts Boolean arguments. The compiler adds a synthetic bridge method getIndex(Object) that basically just delegates but with a cast. That's where we fail then.

Ah yeah of course, missed that. I wonder if we should keep that though - having the "wrong" value of the right type return -1 is okay, whereas the wrong type altogether feels like a larger error (as would be the case for nearly/if not all other generic-type situations like this). As it is the default implementation would throw a CCE if the wrong type is given anyway

[dordsor21]

Can the check also be added to other places (e.g. https://github.com/IntellectualSites/FastAsyncWorldEdit/blob/main/worldedit-core/src/main/java/com/sk89q/worldedit/world/block/BlockState.java#L321 // https://github.com/IntellectualSites/FastAsyncWorldEdit/blob/main/worldedit-core/src/main/java/com/sk89q/worldedit/function/block/SnowSimulator.java#L124-L129 )? Related to #2963 - what should we do in that case?

[dordsor21]

So this isn't actually fully fixing the issue. It's possible to have properties of the same type, with the same length of values, and the same name (i.e. slab and chest type).

[PierreSchwang]

LGTM