Implement unregister functions in CraftingManager

[ShockedPlot7560]

Introduction

Actually, if we want to delete or replace a recipe, we have to go through Reflection.
This PR provides a means of deleting a recipe to make it disappear, or replacing it by register it immediately afterwards.

There's no need to provide any functions other than this one, as the rest does the job:

• Find a recipe from its output
• Add a recipe
• Delete a recipe (allowing replacement by combining the two)

Relevant issues

• Fixes Allow removing crafting recipes #5664

Changes

API changes

Add the following functions to the CraftingManager class:

• unregisterShapedRecipe
• unregisterShapelessRecipe
• unregisterPotionTypeRecipe
• unregisterPotionContainerChangeRecipe

Add the following function to the FurnaceRecipeManager class:

• unregister

Backwards compatibility

I didn't want to do it directly, to get an opinion, but the observers should be renamed. It now only listens to the registration but also to the deletion.

Follow-up

• Renaming observers?

Tests

Will remove all craft for Crafting table

$craftingManager = $this->getServer()->getCraftingManager();

foreach($craftingManager->matchRecipeByOutputs([
	VanillaBlocks::CRAFTING_TABLE()->asItem()
]) as $recipe){
	if($recipe instanceof ShapedRecipe){
		$craftingManager->unregisterShapedRecipe($recipe);
	}elseif($recipe instanceof ShapelessRecipe){
		$craftingManager->unregisterShapelessRecipe($recipe);
	}
}

[dktapps]

Code looks OK, although I haven't tested this myself.

[dktapps]

Things to watch out for:

• This code permits recipes to be unregistered at runtime. This might be fine, but we need to make sure that looking up a recipe that's been unregistered doesn't cause anything to crash (e.g. ItemStackRequest).
• Recipe net ID generation in CraftingDataCache must continue to use the existing keys. The existing keys of the index must not be changed by any recipe being unregistered.

[ShockedPlot7560]

Does this PR require any further development action or is it just testing?

[dktapps]

no, I think the PR code is probably okay.

[ShockedPlot7560]

Fixed #5286

[dktapps]

$changed would be more consistent with code convention

[dktapps]

same again here

[dktapps]

The code in the PR looks functional.

The thing I'm dubious about is that this code expects plugin devs will have to get the exact instance of the recipe they want to unregister, in order to unregister it. I'm not sure this is the best way to go about it.

May well result in some painful headaches if someone does something like this:

$craftingManager->unregisterShapedRecipe(new ShapedRecipe(
    [
        "WWW",
        "W W",
        "WWW",
    ],
    [
        "W" => new ExactRecipeIngredient(VanillaBlocks::OAK_PLANKS()->asItem()),
    ],
    [VanillaBlocks::CHEST()->asItem()]
));

This code looks fine, but it would not produce the intended result.

Basically, I think we need a better way to compare recipes before implementing this.