Support very large game states

[domob1812]

The implemented undo system works well for games with "medium" sized states (where the undo data is much smaller than game states). For very small game states, #3 will provide a simpler solution. But the current undo implementation breaks down if game states get so large that they cannot be easily held in memory or copied around - think ~gigabytes, like Bitcoin's UTXO set.

[domob1812]

To support very large game states (that are not held in memory entirely), we can make the GameStateData object a handle. Games can even do this themselves right now, by simply returning an arbitrary, short identifier as game state and then handling the lookup and management of game states properly in the processing functions and their storage.

But we can probably tweak the library's design a bit to make this easier.

[domob1812]

For games that want their state and logic in SQL, treelite might be an interesting option. With that, the "game state" from libxayagame's point of view could just be the commit ID and the undo data the previous commit's ID.

Of course, this needs some analysis of how efficient treelite is compared to a database that does not track the full history and/or if it allows "squashing" previous, no longer needed commits. If it looks useful and efficient enough, we could even implement that in a TreeliteGameLogic class inside libxayagame.

[domob1812]

14 implements a concrete version of this, namely for large states in SQLite. That is likely good enough for the forseeable future, so I'm closing this now.

If it turns out that we need more general support for "handle based" large states that are kept externally, the code in #14 (mainly sqlitegame.hpp and sqlitegame.cpp) could be split into general large-state logic and specific logic for SQLite.