add application lua kernel and game launcher lua wrapper object

The application lua kernel is meant to interpret scripts to drive
the client. Its main features are, it stores a script in its
registry and provides a C++ function to call it with a config
as its argument. Its initialization also creates a "game_launcher"
object, which stands as a limited lua proxy for the C++
game_launcher object.

The game_launcher object is a table, holding a pointer to the
actual game_launcher it represents, and with metamethods to return
version info and the command line arguments. It also holds
callbacks to set the script for the current application lua kernel,
and to call the "play_multiplayer" function of game_launcher.
Currently it is readonly and you cannot write to its fields,
although that may change to allow the target server to be reset,
etc.

Some minor changes that are included in this commit:
- the actual C++ game launcher object provides an accessor to the
command line options.
- the scripting/lua_types.hpp file now has include guards
take cmdline arg for lua scripts to execute at application start

If a lua script is passed as an argument to wesnoth, wesnoth will
actually instantiate the application_lua_kernel defined in the
previous commits, initialize it, and run the script in that
environment.
add option to allow "unsafe" lua scripts, with "package" package

This allows lua scripts to access the OS, the network, etc.
add multiplayer proxy object for lua scripts

This commit adds the "multiplayer" proxy object to the lua
environment. It also adds an underlying "lua_mp_interface" object,
which acts as an intermediary between lua and C++.

- The mp interface object stores a queue of lua requests, which
are generated by the lua script and stored rather than executed
immediately.
- The mp interface object tracks the pointers to the active mp::ui
objects, avoiding the need to do this in lua and simplifying the
lua scripts.

The reason for the interface object is, we don't want the lua api
here to be tightly bound the implementation of these mp::ui's,
because the mp::ui's are slated to change anyways and become gui2.
Having the interface means that, a programmer can make big changes
to the mp::ui's and as long as they can still find ways to support
the script requests, they won't break any of the scripts.

The reason to use a request queue rather than to immediately
execute C++ callbacks when lua makes a request is essentially just
for ease of debugging later. With this system, when a script is
run we can dump the queued lua requests when we need to debug it,
and in general the stack traces from gdb won't have lua functions
like lua_pcall etc. from the lua interpretter, so it will be a
bit friendlier.
update the gui2 unit test remove list

I'm not completely sure why this is necessary, I think the include
structure for some of the gui2 windows may have changed subtly as
a result of previous two commits.
fixup: update a comment