Decoupling ExecutionStack from GameContext

After putting some significant work into the Skill system that EDEn
will be using, I realized I was passing GameContext around to nearly
every new class I was writing because it was the only way to access
certain objects. That's when I realized the usage of the Context object
was getting
out of hand.

Many game states will need access to common instances of services, like
the ScriptEngine or the ExecutionStack. And making these accessible via
dependency injection is a great way to control how these instances are
initialized, used and tested. However, bundling these objects in a
Context object, while innocuous at first, makes it too easy to start
passing the entire world to every object. And while we aren't at that
point yet with EDEn, the GameContext is in a lot of places and it's
important to keep evaluating its usage and making sure that it doesn't
become a "God object".

This commit removes the ExecutionStack instance from the
GameContext and ensures that it gets set explicitly on each GameState
as it is processed by the one ExecutionStack instance in the game.
Since GameState's access to ExecutionStack is protected, this means
only GameState objects can actually access the ExecutionStack. That
means that each of the MenuState subclasses does the work of navigating
between the states, instead of deferring to a view model, which makes
the MenuState objects act more like Controllers (as they should be).
Places that originally
took GameContext objects but really only needed the ExecutionStack now
get the ExecutionStack directly. This has led to some more granular
parameter passing, but now several classes have way less access to
things they don't need, which is how it should be.
Making GameContext fields accessible only to GameStates

In order to ensure that the GameContext object is only passed around to
initialize GameStates (which need all of the different objects inside
the GameContext), I made GameState a friend of GameContext and made all
of its getters private.

Friendship is not inherited in C++, so GameState now exposes protected
getters for the GameContext fields, allowing all the subclasses to get
at context data without requiring any other "friend class" declarations
other than GameState itself.

Similar to the last check-in, this forces non-GameState objects to act
on only the specific objects that they need. In particular:
- DataViewModel now queries DataMenu for save-game slot information.
- PlayerData and all its constituent fields (characters, equipment,
shortcuts, inventory, etc.) no longer use a GameContext; just the
Metadata object that they need. And for this they have access to a
read-only instance.

After this, cleaned up includes in files that included the GameContext
and GameState headers but no longer depend on them.