add "synced_context_id"

the plan is to allow non-current-players to send require_random.
make server read "context_id"
every client asks server for random seed.

this breaks mp compability.
count requests instead of synced contexts for require_random
comment fix
Merge pull request #334 from gfgtdf/wesnothd_sides

allow every client to ask for random seed.

assume this scenaio:

[scenario]
## human sides 1,2
  [event]
    name = prestart
    [message]
      speaker = narrator
      message = "Hello"
    [/message]
    {GENERIC_UNIT .....}
  [/event]
[/scenario]

previously, in this scenario client 2 would have to wait for side 1 to click away the [message] because of the random seed required by {GENERIC_UNIT ..} because only client 1 was allowed to ask the server for a random seed (Note that waiting during prestart event means black screen), this patch is intended to fix such situations.
simplyfy mpsync

That huge block in pull_remote_choice existed becasue we don't want to
return becasue we dont wan't to make choices for sides that we only
controll  temporary.
With the 'new' idle controller type this can be simplyfied by just not
making choices for idle sides.
add a comment
simplyfy mpsync

this is not needed anymore
fix unused variable warning
Fix spelling in destructor
Merge pull request #336 from naclander/patch-1

Fix spelling in destructor
simplyfy :controller logic
fix viewing side after idle controller reassign
fix request_control_change

if we resigned an idle side that was not the currently active side it
caused bugs before.
Merge pull request #337 from gfgtdf/wesnothd_sides

 simplyfy :controller logic
fix windows document folder name with unicode usernames

http://gna.org/bugs/?22983
Update .travis.yml

add a report of the actual precise version info of the compiler
add notes about print being replaced in lua
add plugins context, manager, create lua thread object

This collection of classes provides a framework whereby the engine
may provide scripting capabilities in any "context". A C++
function may declare a plugin context by providing a list of names
function objects, then may call "play_slice()" on this context to
transfer control to lua. A lua script may generate some arguments
and request to call some of these, then yield to the engine. C++
will run them until one of them signals an error, or that the
context is now invalid (using a boolean return value).

The intended semantics is that lua may only make requests
corresponding to the current context. As soon as a new context
is used (play_slice() is called again) the old context is invalid
from lua's point of view -- calling those functions is a lua
error but not undefined behavior. This should be the case even if
the old context has not been destroyed yet in C++, for instance
if a lua request resulted in a new context being created. There is
a system of locks in place to ensure that when old contexts are
invalidated, stale requests are discarded.

We also add the coroutine library to our lua base. This because
threads are run as coroutines, and writing them requires the use
of coroutine yield from the standard library.