Initial Implementation

[HLXII]

Initial implementation for a version update framework to get the ball rolling a bit.

When updating games to newer versions with new/updated content, it might be necessary to modify the save file a bit to match the new game implementation. Some examples of this include:

1. Removing save data for content that was removed from the game.
2. Giving players a refund for currency if some update caused some balancing changes
3. Updating the save data structure if the game framework has been refactored in some way.
4. Etc.

This PR is to allow users of IGT to implement version updates for their game.

We've added two new protected properties to IgtGame. version will be a semantic version string to match the game's current version. This will need to be updated with the game by the user as their game is updated. saveUpdate will be an optional property in case the user doesn't want to implement a version update framework for their game (if the game is simple enough and won't have any new updates).

the saveUpdate property is defined as a new IgtSaveUpdate abstract class. This will be extended by the user to implement their own versionUpdate callbacks, which is dictionary of semantic versions associated with an update callback function that will update the save data for that version.

Additional Areas of Development

Currently the version update handling is bare bones. There isn't any handling for errors/crashes on updating the save data, which might cause the game to not load properly if there is an invalid save update.

The saveData is defined in IgtGame as Record<string, unknown>, which isn't exactly helpful when handling the version updates as nothing is defined in TypeScript. However I believe this is probably the best implementation/shouldn't be touched. as strongly defining the save means that older version updates may become broken as the save structure evolves. The downside is that having a undefined save structure can lead to fairly obscure update code and is prone to errors.

There might be common version update logic that could have pre-built helper functions implemented. A couple of examples:

1. Shifting array data
2. Increment Statistics/Settings

I haven't used this implementation yet (mostly because it's not part of the library yet :) ) so we'll see how much this needs to change.