feat(cli): Add -saveatframe and -saveto options

[bobtista]

• Fixes No command line option to write a save at a chosen point #3134
• Follow up for feat(cli): Add -loadsave option #3001
• Merge after feat(cli): Add -loadsave option #3001

-file starts a map from the command line and #3001 loads a save from it, but there is no way to write one, so a save/load round trip cannot be run unattended and an xfer change has to be checked manually through the in-game menu.

-saveatframe <frame> now requests a save at the first player-saveable start-of-frame boundary at or after that logic frame. The hook runs before scripts, terrain, and object updates, matching the engine's normal save timing: TheGameClient->UPDATE() precedes TheGameLogic->UPDATE().

If input is disabled eg during a cinematic, the save is deferred until input is enabled. This prevents the harness from creating a save that the in-game Save button would reject. (I tried loading a save made during a campaign mission intro, and it's bad)

-saveto <file> names the file, defaulting to commandline.sav. Both options are registered alongside -file in the debug-only section of paramsForEngineInit, so release builds are unaffected.

The earlier draft placed the hook after logic-frame work had begun. Reloading that mid-frame snapshot repeated work already represented in the save, producing a permanent AI-group ID skew in continuous-vs-loaded CRC comparisons. Moving it to the start-of-frame boundary removes that harness artifact.

Verified on MD_CHI01 with the save/load determinism harness:

-saveatframe 1780 -saveto crctrans.sav
  save deferred while input was disabled
  Command line save to 'crctrans.sav' at frame 1781 returned 0

-loadsave crctrans.sav
  loadGame result=0 file=crctrans.sav

Todo:

• Save at a valid start-of-frame boundary
• Defer while player input is disabled
• Verify the save loads through -loadsave
• Replicate to Generals