Overhaul 'SwitchIn' event for more accurate effect resolution order

[pyuk-bot]

This doesn't include a fix that lets it copy multiple Intrepid Swords, unfortunately. That still needs a larger refactor to how events trigger after simultaneous switches in.

Edit: now it does. Sorry, I got a little carried away.

[DaWoblefet]

Some minor notes on the tests.

[DaWoblefet]

Extra debug print

[DaWoblefet]

Since we're checking statStage on the same mon a bunch, add a fourth argument to these with a string indicating what should be happening (so if the test were to fail, it's more obviously apparent where it's failing)

[pyuk-bot]

Some notes about this refactor: the 'SwitchIn' event now affects every Pokemon on the field at once, similar to the 'Residual' event. Indeed, it now uses the same function, which has been renamed fieldEvent. 'fieldEvent' now accepts a targets parameter, used by the 'SwitchIn' event to indicate which Pokemon switched in; when targets are specified, event handlers will not run for other Pokemon on the field unless they are 'onAny' handlers.

The 'Start' event is no longer run for abilities and items during the 'SwitchIn' event. Instead, abilities and items with an onStart handler but no onSwitchIn handler automatically get the former copied into the latter. As such, many abilities and items now have an onSwitchInPriority set despite not having an explicitly defined onSwitchIn handler.

Handler resolution order has been reworked to automatically sort effects so their handlers activate in the same order they do in-game. This preserves hazard activation timing within the 'SwitchIn' event and simplifies effect order sorting in general. In order to preserve the activation order of multiple hazards on one side, effect state objects now all have an effectOrder property that tracks when the effect became active. This lets us sort older effects before newer ones, similar to how the games sort handlers. To facilitate this, EffectState has been made into a class to give it a constructor that automatically handles initializing the effectOrder property. This property also replaces abilityOrder, as it accomplishes the same thing.

The events 'PreStart' and 'Primal' have been rolled into the 'SwitchIn' event, and their respective handlers have been given higher and lower onSwitchInPriority appropriately. Code that checks if an item is an Orb which causes primal reversion now uses the new isPrimalOrb property rather than checking for an onPrimal handler.

Speed is only sorted once at the start of the switch-in event block in-game, which includes speed ties. To replicate this, an array of fractional values in the range [0, 1) are stored by the Battle object; this array is randomly shuffled at the start of each 'SwitchIn' event, and its values are added to handler speeds to guarantee they are sorted in the correct order.

[pyuk-bot]

Several tests have been unskipped, as the mechanics they check for now work correctly. The two tests currently failing are both related to Commander, and before I can fix them I need confirmation on some mechanics questions. The eject pack one was written when Commander activated instantly instead of waiting for its turn in the switch-in event order, and now Intimidate correctly activates first, so I'm not sure if the test's assertions are accurate to the games. If they are, then this test is failing because Eject Pack is bugged in a way that I didn't fix as part of this refactor because I didn't have the relevant information on its activation timings. As for the other test, the issue is that the Tatsugiri already has Commander, so when it transforms into another Pokemon with Commander, its ability isn't restarted. However, Commander's onUpdate handler waits for the ability to be started, so after transforming it can no longer activate. I know how I could fix this now without changing any other behavior, but I'd like some confirmation on the mechanics of why the ability isn't restarted in the first place. I suspect other ability data may not be reset in game like its handler order, i.e. transforming wouldn't change a Pokemon's place in the Lightning Rod redirection order if its ability doesn't change.