Fix replaceable interaction with matchers

[rymiel]

Bolt checks if a block is replaceable based on the replaced block state, but runs matchers based on the new block state. This can cause situations where Bolt matches a chest protection, assuming the replaced block is a chest, while also thinking its a replaceable block, thus cancelling the place.

This patch checks that the replaced block is of the same type as the protection. This is because replaceable blocks, if protected, would only match themselves, and they cannot support other blocks.

[pop4959]

Implemented this fix in an alternative way in 080cfa7 by checking for the destroy permission instead - since it's totally fine for the owner of a protection to replace their own protection (or anyone that is allowed to destroy the original protection, in any case).

[rymiel]

That works for the issue that was being fixed because it was event order jank, but technically if the block itself was protected and you replace it, won't it create a new protection without removing the old one, leaving two protections for the same block, one of which is desynced?

[pop4959]

That works for the issue that was being fixed because it was event order jank, but technically if the block itself was protected and you replace it, won't it create a new protection without removing the old one, leaving two protections for the same block, one of which is desynced?

Maybe, I just wasn't sure how to test that. If there's a bug with it there might be a bit more code that needs to be added here (to unregister the old protection and add the new one, if it's in the same location as the clicked block).