Restrict modifying signs

[Jikoo]

Restricts wax in general, so in the event that Mojang adds more waxables that Spigot doesn't fire a BlockPlaceEvent for, should be supported.

I'd like to take this opportunity to gripe about how inconsistent Spigot is about BlockPlaceEvents for actions that change states, even if cancelling interaction is much more performant. Book on a lectern? Yep, that's a block place, new state. Wax on a sign? Eh, the state changed but it's really just a sign still.

/e: Forgot the issue, whoops.
Closes #2060

[Jikoo]

Based on the fact that the SignEditEvent doesn't seem to be firing reliably from editing unwaxed signs it's safer to preemptively block sign interaction for editable signs. This does cause some redundant sign snapshotting for non-malicious usage, but that is much less likely to cause a performance impact than malicious usage.

[RoboMWM]

huh, why is SignEditEvent not always firing reliably?

[Jikoo]

My best guess is that Mojang added it in a hacky way to handle the case where someone waxes a sign after you place it but before you finish writing the text. You'd think that that would basically just use the original placer as a flag, but I've seen a couple threads and issues about the subsequent unwaxed edits that suggest that it doesn't fire an event at all, meaning it's internally an entirely different code path.

[RoboMWM]

Idk if you can make a todo issue/improvement for when we switch to 1.20 API (probably will do that with v17 release, unless something major requires an API bump).

[Jikoo]

Yeah, that's a good idea, I'll generate an issue from the line.