[26.1] Fix potential desync in BrewingStandBlockEntity.doBrew

[ApexModder]

This PR fixes a potential desync and oversight in BrewingStandBlockEntity.doBrew, where the PotionBrewEvent.Post event allows users to modify the ingredient slot via the setItem method.

While the event does modify the backing NonNullList the doBrew method relies on a local ingredient field which is not correctly updated after the event has fired leading to this desync.

This is fixed by simply refreshing the local fields value after the event to pull in any potential mutations that might have occurred.

Note: Initially opening as draft as this PR may need updating after #3179 has been merged to ensure the crafting remainder line is correctly below the patched in field refresher line

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[ChampionAsh5357]

For transparency, there is still the open question of whether mutation should event be allowed in the post-event. This is just one solution depending on the assumptions made.

[ApexModder]

If we prefer not to allow mutations via the Post event the other fix I would suggest is moving the setItem method up into Pre from the base PotionBrewEvent.

While this would be a breaking change it would ensure changes via the event happen before doBrew occurs and always runs with the most up-to-date values

[neoforged-automation]

@ApexModder, this pull request has conflicts, please resolve them for this PR to move forward.

[sciwhiz12]

I think part of the problem here is that we have two pathways where Post is invoked:

1. If Pre is not cancelled, then vanilla brewing takes place, then Post is fired.
2. If Pre is cancelled (i.e., by a mod inserting its own logic in place of vanilla), then Post is fired.

If we go by the usual pattern that Pre is mutable and Post is immutable, then it would not be possible for a mod to react after vanilla brewing and modify the outputs, because Pre is fired before vanilla brewing is invoked.

What I'm thinking we could do here instead is to refactor PotionBrewingEvent.Pre such that it contains both input stacks and output stacks, and is fired after vanilla brewing with both inputs and outputs.

Mods can then react to vanilla brewing or fully replace it with their own. Post could be retained as a final event after a successful brew.

What is questionable in this is the role that cancellation of the Pre event plays here. Currently, cancelling it has three effects: the contents of the brewing stand are overwritten and vanilla brewing (including the associated level event) is skipped, but Post is still fired. I'm not sure how best to deal with that.