Fix max rollback and lockstep handling

[caspark]

NB: This builds on PR #82 so we better merge that one first to make this diff easier to review. (is Github working on stacked diff support yet?)

---

This fixes several issues that (I am fairly certain) came from merging #79:

• When at the limit of the prediction window, rolling back would crash. This is fairly easy to trigger by adding a lot of latency in a network simulator. The cause was an off by one error in SavedStates' calculation of how many states need to be saved.
• Clearer logic controlling when it's okay to request advancing the frame. I am not 100% certain but I suspect that the Fix/Feature: Lockstep #79 logic wasn't handling NULL_FRAME correctly? In any case I think this new structure makes it a lot easier to reason about.
• Lockstep mode specific stuff:
  • Document lockstep mode as first class thing.
  • Fix disconnect handling in lockstep mode; previously the game would crash if a player disconnects (trying to rollback to the current frame, or perhaps the frame before the current? I can't quite remember). The fix is to skip all the "should we roll back" logic entirely if lockstep mode is on.
  • Make lockstep mode not issue save requests ever, since that's pointless - and besides, the fix for the previous bullet makes this almost necessary.
    • Because of this, we also need to turn off sparse saving mode in lockstep mode, since sparse saving mode somewhat confusingly causes us to not mark frames as confirmed, and not having frames confirmed means we won't advance.
    • Update example to more easily catch the case where lockstep mode is on but somehow we got issued a save or rollback request, by panicking in that case.

I have tested manually with 2 and 3 player example games, with lockstep mode and 8 frames of prediction and with sparse saving on and off. In a previous version of these fixes (those on the main branch of my personal fork) I also did a lot of testing with high latency and such to verify the "rollback when at limit of prediction window" fix, but in the name of full disclosure, I haven't done that with this branch specifically (I have a smallish test harness that makes it easy to do that testing with my game and my ggrs fork).

Anyway, based on that testing, everything seems to work.. but this is fiddly stuff so 🤞. I am at least pretty confident that it's more reliable than what's in main currently :)

[caspark]

Ideally we'd log a warning (or at least at debug level) here to let the user know their sparse saving request is being ignored, but we don't have a logging framework right now.

Edit: raised #89 to discuss adding some logging.

[gschup]

this looks good, but the commit history needs to be cleaned up. thanks for all the good work on ggrs :)

[caspark]

Oh, sorry, I had actually squashed some commits locally to remove the WIP and dead end commits, but I forgot to actually push that! Have rebased onto main again now.