feat: Add MaxSerializationLength() to Game API

[amyssnippet]

i added a new virtual method MaxSerializationLength() to the Game class which allows consumers (especially in JAX/vectorized environments) to pre-allocate fixed-size string buffers for state serialization without guessing or over-allocating.

Changes:

• Added default implementation in spiel.cc based on MaxGameLength and action digits.
• Overridden implementation for Chess (accounts for FEN + history).
• Overridden implementation for Tic-Tac-Toe (fixed constant).

This should help unblock the JAX vectorization work mentioned in #1452.

[lanctot]

Thanks!

[amyssnippet]

Thanks @lanctot! Since all the checks have passed, is this ready to be merged? Please let me know if there is anything else you need me to adjust.

[lanctot]

Oh it will be a while before it's merged, sorry. I haven't even looked closely yet. There are several PRs ahead of this one, and I have to discuss with the team if this is the best way to introduce it.

It'll be difficult to provide a sensible bound on serialized strings in most games. I'm not sure why the bound should be on the serialized string rather than e.g. the observations. The serialized string for most games will be linear in the history, which can be quite large. I suspect the authors of #1452 didn't have that in mind and don't plan to pre-allocated vectors of maximum history size (they might not realize the serialized strings are linear in the history, they're probably thinking of the serialized strings as observations.. and in that case it would make more sense to have a bound for State::ToString). So I need to respond on that thread to clarify this first.

And we definitely won't be able to add the missing ones, so it'd probably be functionality that would have to exists locally for whoever uses them anyway (unless they get contributed for each game, which I seriously doubt).

[amyssnippet]

@lanctot Thanks for the feedback. I completely agree that for many games, the serialized string grows linearly with history and can be large.

so could we keep the default implementation safely returning "Not Supported" (or a calculated estimate based on MaxGameLength where possible), and only override it for the specific games (like Chess/TicTacToe) where we know the bounds? This unblocks the specific use case in #1452 without forcing a rewrite of every game in the library.