📚 Break down the status effect state machine into smaller steps

[tomrijnbeek]

✨ What's this?

This PR breaks the existing logic for elemental status effects into smaller steps that different scopes can hook into.

🔍 Why do we want this?

For multiple status effects we were doing a bit of a hacky approach where we were reapplying their upgrade every tick. With this approach, there are now multiple points where the scopes can hook into changes to the active effect so they can only update certain things when needed.

🏗 How is it done?

The lifecycle of status effects is now as follows:

Method	Called when	Used for	Returns
StartScope	When the scope becomes active because any effect will become active	Initialise common elements such as visual components that do not rely on effect instance	Can set an out ElementalStatus to apply a status icon
StartEffect	Whenever a new effect in this scope becomes active (may be multiple times per StartScope)	Apply elements specific to the current effect instance (e.g. apply an upgrade)	Can call ChangeStatus on the passed in context object to change the status icon to something new
ApplyEffectTick	Each tick as long as the scope is active	Apply recurring effects (e.g. damage over time)	-
EndEffect	Whenever an active effect stops being active (a new effect may start immediately with StartEffect)	Clean up all elements from StartEffect, including undoing their effects if needed	-
EndScope	When the scope becomes inactive because all active effects expired	Clean up all elements from StartScope	-

As mentioned in the table above, I passed in a context object in StartEffect that allows modifying the status. Perhaps it can be used for other things as well. Taking this approach a step further, we could even have the context object automatically be responsible for cleanup (e.g. context.ApplyUpgrade(upgrade) could automatically undo that upgrade when the effect ends). For now, I decided to stick to the bare minimal requirements to see if this approach is worth pursuing at all.

💡 Review hints

1. I'm not particularly happy with the naming of the lifecycle methods. Suggestions for better names welcome