Baritone Tick Phases

Currently, event priority is done through the order that behaviors are registered in. As a result, `PathingControlManager` relies on `PathingBehavior` to call its `preTick` method, and `postTick` is called by registering an event listener after all behaviors have been created and registered.

I think a much better solution to this problem would be to outline the phases in which Baritone needs to execute its code every tick. I'm proposing something like:

1. **PreTick**
- Called at same time as existing PRE TickEvent
- Used for setup that may be required in multiple different places
- LookBehavior AimProcessor tick
- InventoryBehavior lastTickRequested
- PathingBehavior queued event dispatch
- ElytraBehavior solver fetch
- etc.
- Incrementing count-down/up tick counters
2. **SetupPath**
- Process is selected for this tick and asked what to do
3. **PreparePath**
- InputOverrideHandler can modify the player's movement input if needed
4. **PostPath**
- Equivalent to PathingBehavior's `postTick` which does the re-validation stuff. Arguably this phase doesn't need to exist and could just go in the PostTick described below.

The actual game tick is executed here, between PostPath and PostTick. The world entities are ticked, starting with the player, and all the player input/rotation changes we've made up to this point will be applied.

5. **PostTick**
- Called at the [very end of the game tick](https://github.com/cabaletta/baritone/blob/4c0c263d1100d5f48caf9bf303ceb7654d73a463/src/launch/java/baritone/launch/mixins/MixinMinecraft.java#L113).
- Used for actions that need to be executed after the game's world tick has completed.
- ElytraBehavior already uses this for queuing async calculation between game ticks.