Add piston move behavior overrides

[SpaceWalkerRS]

This PR adds the ability to change how any block interacts with pistons through a command. This is done by giving each block state a piston move behavior 'override' that can be changed or removed.

The command structure is as follows:

• /pistonmovebehavior get <block>: returns the piston move behavior of the given block state, and whether that is vanilla or modified behavior.
• /pistonmovebehavior override <block>: returns the override of the given block state.
• /pistonmovebehavior override <block> <new behavior>: sets the override of all block states matching the given set of properties to the new behavior.
• /pistonmovebehavior defaultOverride <block>: returns the default override of the given block state (i.e. the value that is saved across restarts).
• /pistonmovebehavior defaultOverride <block> <new behavior>: sets the default override of all block states matching the given set of properties to the new behavior.

Things to note:

• The command can be disabled with the commandPistonMoveBehavior rule.
• Block entities remain immovable unless the movableBlockEntities rule is also enabled, and the moving_piston block cannot be made movable.
• The default overrides are saved in ./<save dir>/carpet_piston_move_behavior_overrides.json.
• The default overrides are saved upon server shutdown and on autosave.
• There are few other rules that modify how some blocks interact with pistons:
  • movableBlockEntities makes some blocks explicitly (im)movable (ender chests, enchanting tables, end gateways, end portals, moving blocks and spawners are explicitly made immovable; command blocks and grindstones are made explicitly movable if movableBlockEntities is enabled). This code has been removed and some blocks are given default overrides "out of the box".
  • movableAmethyst makes budding amethysts movable and harvestable. I have renamed the setting to harvestableAmethyst and removed the code that makes it movable (since that can now be done with the new command).

[SpaceWalkerRS]

I'll set this as a draft while awaiting #1505.

[gnembon]

Sounds like an overengineering is happening here? Is it really needed to have a that fine control? It would make sense probably to have just a list of predefined options (at best)? what these options would be? I do hate tags in non-vanilla settings, but that would be a perfect place for a block tag, right?