Add openSaveMenu Lua function for save point NPCs

Scripts can now open the Data Menu, thus allowing for NPCs to be
designated as “Save Point NPCs”.
Extracting PlayerData from GameContext

Removing GameContext::getCurrentPlayerData() by using dependency
injection in the constructors of GameState classes that expect player
data. This is a little odd because I just did quite a bit of work to
move PlayerData to GameContext just to avoid the extra parameter, but
it’s for good reasons.
Prior to this change, there was one “current” PlayerData instance
constructed in the GameContext. From a design standpoint, this made
MainMenu kind of an odd state because it had a PlayerData, but had to
modify or reset the state of that data any time a TileEngine was either
created or destroyed. Since MainMenu doesn’t depend on a PlayerData
(and neither does SettingsMenu, for that matter), it doesn’t make sense
that the lifetime of PlayerData precedes them.
The other benefit of this approach is the ability to separate
SaveLocation from PlayerData. PlayerData didn’t really do anything with
SaveLocation, and it didn’t make sense to persist it in the PlayerData
class after its initial load. Instead, we will soon be able to create a
loader that gets both the SaveLocation and PlayerData from any given
save file, and uses the SaveLocation only on game load.
Saving game now saves player location

Removed “valid” flag from SaveLocation, replacing it with an isValid
function that checks for valid location data.
Removed SaveLocation instance from PlayerData. It’s now passed in on
PlayerData::save and returned inside the result of PlayerData::load.
PlayerData::load now returns a PlayerData instance and the SaveLocation
from the save game file.
Cleaned up how TileEngine initializes itself. Constructing a TileEngine
now *requires* a chapter string or a save location, and it is not
possible for other classes to initialize a TileEngine without these.
DataMenu has been augmented to take a SaveLocation, which can be easily
created and passed by the TileEngine.
Fixed failure to block NPC activation script

On activation, an NPC runs its activation function (if one is
available). If this function yields and blocks, then it should not
continue running right away. Fixed the NPC resume function to return
after calling its activation function, so that it doesn’t resume right
away if the activation function needs to wait on something (such as
dialogue or player action).
Menu/DataMenu.cpp -> Menu/DataMenu/SaveMenu.cpp
DataMenu becomes SaveMenu, a root-level menu

Since DataMenu is going to be used outside of the context of a regular
in-game menu, I’ve removed its inheritance of MenuState and made it a
top-level menu that doesn’t show a Shortcut bar or a Shell.
I decided to put all the DataMenu functionality I’m planning to create
into a subfolder of “Menu”. I’ll put the MainMenu directory in there
too in a future commit.
Removing workaround for CMake bug

Originally, CMake and Xcode didn’t play nice when creating a root
source group. In fact, it caused Xcode to crash when loading the
generated .xcodeproj. This no longer happens, either due to a CMake fix
or an Xcode fix. Either way, the check for Xcode before running this
script line is no longer needed.
Moving SaveMenu data logic to a Model object

SaveMenu was dealing with too much by being both a Model and a
Controller simultaneously. It required me to pass SaveMenu to anything
that needed to operate on save game data (such as the SaveMenu view
model). This has been fixed by splitting out the save game reading
logic and saving logic into a SaveGameModel class.
DataViewModel -> DataMenu/SaveGameViewModel
Adding a Load Game menu

SaveMenu can now be initialized as a Load menu, in order to allow
players to load a saved game and pick up where they left off.
Fit and finish on save menu