Feature: Add recipe unlocking on Bedrock edition

[onebeastchris]

Hey!
Since 1.20.10, there's a recipe unlocking system. Since it is currently still experimental, we would have to enable "recipe_unlocking", but the good thing here is, that old versions would be unaffected by this change.

Changes necessary:

• When java sends a ClientboundRecipePacket, a recipe id is sent instead of a full recipe. Hence why we need to store all Bedrock recipe identifiers for all matching Java edition recipes.
• MultiRecipes are not sent, and appear to be always unlocked.
• While we could still just use random uuid's as the recipe identifiers, using the java identifiers wherever possible could allow reducing the stored recipe identifiers to only those that do have multiple Bedrock recipes Doesn't really matter

Left to do:

• More testing, lol
• Add java recipe identifiers to our recipe.json mappings - otherwise, those would never be unlocked Turns out: While Java edition has recipe identifiers for these special recipes (e.g. minecraft:suspicious_stew, or minecraft:shulker_box_coloring, or minecraft:tipped_arrow), which do show up as autocomplete options with the /recipe command, those cannot be given/taken away, and they do not show up in the recipe book on Java edition - hence, we probably shouldn't either :p
  Edit # 2: while java doesnt unlock these, we probably will do so forcefully - to make sure it works similarly as it does on Bedrock edition itself.
• Smithing templates/trim recipe unlocking
• Add furnace/blasting/smoker recipes - while there is no use for them on Bedrock as far as i can see, BDS sends them, so i would assume they might add that in the future. Also, the pop-up is still there I was mistaken. Bedrock seemingly sends them during recipe definition, but doesn't actually lock/unlock them - however, this might allow us to define custom furnace recipes? probably not though. EDIT: No need to add/translate these currently - custom recipes already work, and since they're not (un)locked, no need to store recipe identifiers. Heck, don't even need to send the recipe :p

Not strictly related to recipe unlocking, but.. why not:
- [x] Only send smithing template recipes if the server does too Implemented in 706d1b9
-Fix hanging sign crafting recipe, presumably related to the chains in the recipe
Geyser broken vs BDS: https://paste.gg/p/anonymous/b62c8fa3ad1247c7bc37e2f17da91760
Geyser works vs broken: https://paste.gg/p/anonymous/38c4eabd01a146af9e68477fd81bbd9d
Seems to be due to the block definition sent in the recipe result.
Not fixing it in this PR, not sure how to fix.

• add multirecipe for decorated pots, should make making them smoother:
  There are two new multirecipe uuids, one for decorated pots (added in 1.19.70.23, see here, and one in 1.19.80; presumably for then added trims?) Java edition also sends a sort of multirecipe once, so an extra case where we also send that multirecipe should do the trick here.
• Allow different wood types be mixed in recipes when appropriate, e.g. shields/campfires/sticks etc. Fixes Cannot craft shield using multiple wood types. #3784 - completed with 81d7386

RFC: What would be the best way to handle storing Java -> Bedrock recipe identifiers? Per session, or versioned registry?

More fun things:
https://paste.gg/p/anonymous/dbafa96a204a40a8a04c997ac4a9c171 all bedrock recipe identifiers (1.20.12 BDS)
https://paste.gg/p/anonymous/fd13b5a490ba47caae96e76eb0e58d86 all MultiRecipes, probably worth checking out what the rest does
Would appreciate some feedback, just for cleaner impl