Cope better with story changes as save file is reused #195

Two scenarios to consider:

• Developers iterating on a story during development of a game. As story changes, it's common to reuse a save file. Ideally ink should cope as well as possible with the changes, but obviously there's only so much you can do, and at some point you have to throw your save away and restart the story.
• Developers iterating on the story after the game is released. It's critical for ink to cope so players don't lose their save data, though it's also down to the developers to understand that the types of changes they're allowed to make are limited. Even if a change is made that's impossible to fully recover from, ink should do its best to cope though.

It would be good to enumerate some possible problems here, and have a think about what the best way to cope is:

• New variable added: X exists in new story, but doesn't exist in old save file. There should be a mechanism for realising that this is a possibility and instantiating new variables with the default value provided in the ink declaration.
• Variable removed: X exists in old save file, but doesn't exist in new story. Mostly harmless I think? The story state will contain extra data that it doesn't need, and will quietly accept new values to be pushed in from the game side where normally it would complain that the variable doesn't exist. (See Bug: Setting global variable from c# can set local variables unexpectedly #193)
• Existing written content removed: If the current saved path (or a choice's path) in the story no longer exists, we should probably try to play with the path to find the smallest tweak that makes it valid again. This can obviously create all sorts of other bugs, but hopefully it would be perceived as a less critical content error. (The internal hierarchical structure of the runtime content was designed to hopefully cope well with exactly this.)
• Knot/function parameters changed: Too many/too few parameters will exist on evaluation stack. Could probably just try to cope with this situation better - right now it simply crashes.
• Content added before a choice point: ...causes the address stored in the save file for the choice point to become invalid, causing a crash on load.

The main problem with trying to be forgiving in these scenarios is that it's hard to distinguish between data changing and there being a bug, either in the story or in the runtime flow.