fix: canPlaceOn and canDestroy will be passed on conversion

[Nerahikada]

Introduction

TypeConverter now also uses canPlaceOn and canDestroy parameters for item conversions.

Relevant issues

• Fixes canPlaceOn, canDestroy have no effect on clients #6460

Changes

API changes

Behavioural changes

Backwards compatibility

Follow-up

This is enough to fix #6460, but still has the following issues:

• Crashes when using new IDs such as minecraft:grass_block
• ItemStack extra data contains unnecessary NBT data:
  • Minecraft vanilla: //8BCgAAAwYARGFtYWdlAAAAAAAAAAAAAQAAABUAbWluZWNyYWZ0OmdyYXNzX2Jsb2Nr
  • pmmp: //8BCgAACQoAQ2FuRGVzdHJveQgBAAAAFQBtaW5lY3JhZnQ6Z3Jhc3NfYmxvY2sAAAAAAAEAAAAVAG1pbmVjcmFmdDpncmFzc19ibG9jaw==

Tests

I tested this PR by doing the following (tick all that apply):

• Writing PHPUnit tests (commit these in the tests/phpunit folder)
• Playtesting using a Minecraft client (provide screenshots or a video)
• Writing a test plugin (provide the code and sample output)
• Other (provide details)

$item = VanillaItems::IRON_HOE();
$item->setCanDestroy(["grass"]);  // minecraft:grass_block or grass_block will crash
$player->getInventory()->addItem($item);

[dries-c]

Would be nice if we could validate whatever is set in setCanDestroy.

[dktapps]

In PM these arrays can accept arbitrary values (by design). Same can't be said for the Minecraft ones, those have to contain actual block IDs. Not sure what the proper solution would be. Perhaps some clunky hack using StringToItemParser and the blockstate serializer to retrieve the ID, but the behaviour still might differ between client & server because Minecraft block IDs don't map 1:1 onto PM block types.

Personally I think this feature is better not bothered with.

[dktapps]

Also worth mentioning that PM does enforce these, but only in adventure mode.

[dktapps]

Closing this as WF since there doesn't seem to be an obvious way to control this by the item's data beside its ID, making it difficult to use with PM-side items without directly exposing Mojang internals to the API. Considering the limited benefit I don't think this is worth bothering with.