DEV: Game engine improvement dicussion

(I am making a separate issue to discuss and collect all of the game engine improvement work since #8973 is not the right place for it).

# Problem
Game engine cannot current "rollback" a state. All it can do is store copies of the current state in memory and load them back if needed. This has two problems:
1. It's incredibly slow and inefficient. It's also part of the reason why games with AIs can significantly slow down. The AI copies the state 10s-1,000s of times every time it gets priority.
2. This copying can cause the whole server to crash in easy to reach scenarios (see #9302).

# Cause
The way that rolling back currently "undoes" an action is by copying the state before the action is performed, and if an undo is needed, to restore that copied state. In order to avoid this copying, the actions (e.g. an effect resolving) would need to have an "undo" method. However without the full history of the game, such an undo is not possible.

# Proposed change
Change the game engine that instead of keeping only the current state, it keeps track of the entire history of the with all of the information required to replay the game entirely. What I mean by this is that the *new* state of the game should be serializable so that it can be saved to disk, and then re-loaded at **any point in the future** (with the same version of XMage) and the game can be picked up **from any point** (either to continue with whoever has priority next, or to roll it back all the way to the first turn) and continune playing.

The operation of all methods/classes which interact with the new game state would function as follows: old state + operation -> new state + side effect (displaying things to screen or writing to file).

In order for this to work, I currently think the following changes are necesary:
1. Change the datastructure of the GameState object to keep track of the history of all entries. This has to be done in a way that keeps track of actions performed in the game. E.g. each action occuring in the game (tapping a land, player dying, state based action, object put on stack) has a counter state before it occured and one after. So that rolling back to the start of the turn involves removing all changes which occured after the counter representing the start of the turn.
2. All objects must be refactored so that the game state contains their internal state. The objects themselves can still have state, but it should only be thought of as a cache for the values contained inside the GameState.

Links:
1. [Delta Compression](https://stackoverflow.com/questions/29310983/what-application-game-state-delta-compression-techniques-algorithm-do-exist)
4. [Design Patterns for Games StackOverflow](https://stackoverflow.com/questions/361002/any-patterns-for-modelling-board-games)