Add LuaGameState class

Project has taken a new direction. For as much as can be done, gameplay
and higher level logic will be carried out in Lua scripts, while keeping
speed-critical code in C++ (especially the game loop). There are two main
advantages to this approach.

 - Less recompilation: When the time comes for level creation, it will be
   beneficial to tweak higher level details without having to recompile
   the code. If these details reside in Lua scripts, it can be accomodated
   easily.
 - Easier expression: The level of abstraction Lua provides will allow
   faster gameplay prototyping. C++ is of course very low-level where
   memory management and resource allocation are omnipresent concerns, but
   with Lua this is handled within the interpreter.

The Purple Pikachu project then should be regarded as an engine. It is fed
input in the form of Lua scripts and outputs to the screen. The game will
rest in the Lua scripts, powered by the C++ engine.

The most natural integration for Lua is within the State system. Lua uses
an environment state instance to interface with C++, and there can be
multiple Lua states for any C++ project. Since the TEMM::State classes
work independently of each other, a derived class LuaGameState can fit Lua
in nicely. LuaGameState wraps an instance of a Lua state and interfaces
with it through its static methods. Though they are static, they ought to
be interpreted as member methods. Object mapping is done through a static
registry of the LuaGameState class, since Lua cannot hold an instance to a
C++ object, only C functions.
Add Lua to State enum, load() to interface

State::load() is a hook method that so far only LuaGameState will have
overridden. This is so that any State referencing code can load Lua code
without knowledge of the State type.
Optional filename for StateStack::pushState()

StateStack clients may now supplement a filename for the new State to load
after being pushed onto the stack.
Push LuaGameState onto Application stack

Application class now automatically pushes new LuaGameState (after
registering the class), which then loads res/lua/test.lua.
Add Lua to CMakeLists

CMake includes a module that finds CMake libraries and include
directories. Use it in CMakeLists to avoid having to link the Lua
libraries often.
Turn LuaGameState into template decorator class

LuaGameState (now LuaState) is now a template class that derives from the
State base class and wraps an arbitrary State derived/peer class (i.e,
decorator pattern). This allows LuaState to be plugged in anywhere a State
is expected, like StateStack, as well as extend the functionality of
existing State derived classes, which was the original purpose.

Traditional decorator patterns do not need templates. This is because the
decorator usually does not care about the type of derived class that it
decorates. In this situation, however, it is necessary that the decorator
LuaState know type information of the State class it wraps. This is
because LuaState provides additional functionality to specific State
derived classes, not just the general State base class.

Rather than create a new decorator class for each derived State class,
polymorphism is achieved through template specialization. The important
method is LuaState::exposeInterface(). It is specialized for any derived
State class that wants to expose functionality to Lua, and it is
automatically called in LuaState's constructor. All other methods are
defined as general methods for arbitrary wrapped States.*

The application at this commit initializes with a Lua wrapped GameState.
To wrap a new state in Lua, an additional boolean parameter is passed to
specify so. There is currently no functionality exposed to Lua.

* LuaState::exposeInterface() is defined generally as well. The program
  will default to this implementation if there is no specialized
  definition. It is a no-op.
Expose GameState functionality to Lua

Specialize LuaState in new LuaGameState.cpp for GameState. Currently only
exposes GameState member Overworld::loadTMX().

Tricky to deal with information hiding in classes. Have to modify
GameState by declaring LuaState as friend class; have to group static
Lua-exposed functions in a private struct in LuaState (redefined for each
template specialization).

Add LuaGameState.cpp to CMakeLists.txt.

Remove test.lua and add startup.lua. Startup.lua will be the first script
loaded automatically by the application. It is the jumping off point for
handing application control to Lua. Modify startup.lua to direct the
application.
Application loads startup.lua in a new GameState

GameState no longer loads the testing TMX file by default. That behavior
has been handed to startup.lua, which can be modified without recompiling.