put simple_rng methods in own file.
add new rng

the plan is to have random_new::generator which can be a rng_synced or not dependng on whether we are in a synced context (for example select events are no synced context)
add replay_helper class
add config_of function
add synced_context class

the intention  is to fix #20871 and implement #21697, to sync
prestart/start events, and to implement
http://forums.wesnoth.org/viewtopic.php?f=6&t=39611 in the next patches,
give a better error message.

when a player leaves a mp game during a lua call and the other player
pressed escape, lua catches the error that should exit the game, idk
wether i can fix that but at least i can give a better error message.
use rand() instead of get_random() for side shuffle

1) i think it's better to use a simple rand function for things that are
never synced, because everyone knows that rand() isn't synced.
2) my plan is to delete the get_random() function.
fixes wrong side during end turn events in replay
fix a bug when players leave in mp.

as pointed out by EliDupree:
http://www.wesnoth.org/irclogs/2014/03/%23wesnoth-dev.2014-03-19.log
serverside code for the new rng.

i might have to change this code again because the following might be
true: 'instead of checking wether we already gave a random seed it'd
would be better to accept only seed requests ffrom the currently active
side'

remove side check for require_random

I decided to implement the check for require_random in the client instead of the server to fix a possible OOS:
to reproduce (assume a server check like "user->first == owner_"  for require_random in the servercode):

[event]
name = "turn end"
[set_variable]
name=v1
rand= "1..8"
[/set_variable]
[/event]
[event]
name = "moveto"
[message]
side_for=2
message="adfsd"
[/message]
[set_variable]
name=v2
rand= "1..8"
[/set_variable]
[/event]

Do the following: (in a 2p scenario, with no hidden sides):
1) move side 1 leader
2) ignore the message on side 2
3) click end turn on side 1
4) then click on the message on side 2.
5) ->>OOS.

the reason is, the when the rand for v2 is executed on side 1 the
current_side on the  server is side 1 and when rand for v2 is executed
on side 2 the serversided current_side is side 2 => the server accepted
both require_random
use new synced_context: use new rng

the plan is, that random_new::generator will be a object that does synced random calls during a synced context and otherwise not,
so that we cannot create OOS anymore by using random in unsynced actions like select event

the intention is also to unfy random calls for attacks and random calls and for other actions like traits and [set_variable] rand= .

the synced random generator will be set with the set_scontext_synced object.

the new rng will be similar to the old rng used for attacks becasue it will ask the server for a new seed for every new user action (=recruit, attack...) that requires random numbers.
use synced_context: fix mp observers

with the new synced_context system, the old code would bring code in the wrong order onto the replay if we received data during get_user_choice
which now could be called during turn_info::handle_turn.

also previous code would fail to process
[turn]
[command]
[move]
x = 3,4,5
y = 4,3,3
[/move]
[/command]
[/turn]
[turn]
[command]
dependent = yes
[input]
[/input]
[/command]
[/turn]
because [input] would be processed after [move] was processed, but
[move] need [input] on the replay to work properly.
(if luas sync_choice was called from a moveto event)

dont forget to execeute previously recorded actions
use synced_context: change ger_user_input

the plan is to sync start and prestart events, so we don't need to check for that anymore,
we also don't need to pass the rng because we can use call random_new::generator->..
use synced context: sync the turn ... events and prestart events.

by using set_scontext_synced and recording brefore doing that.
the main intention of that patch is to fix gna.org/bugs/?20871,
gna.org/bugs/?21697, some OOS erros related to use of multiple
[get_global_variable] with different sides in one event.
To remove the deterministic random for traits and similar as discusssed
here http://forums.wesnoth.org/viewtopic.php?f=6&t=39611. And to sync
start end prestart events.

this patch unifies how side commands (like attack, recruit, ...) are
executed, during human turn, replay or ai turn by makeing them al call
the same function scned_context::run_in_scned_context.
We also use the new random generator which is automaticly synced during
the execution of scned_context::run_in_scned_context, and otherwise not.
So we cannot cause oos anymore by using rand= from an unsnced command
like "select"
Alternativeley we can also set the new random synced by using the new
RAII object set_sconext_sycned, this happens for example during prestart
events.
Unlike the old random generator, the new random generator is not
determinstic by default because it asks the server (or itself in a SP
game) for a new seed, at every side command (attack, move, recruit ...)
that requires random ,similar to how the previous rand for attacks
worked (it doesnt ask at the beginning, just the first time it is needed
unlinke how attacks worked before). That way we can also unify the rng
for attacks and for other random choices.

this commit breaks ai's advancement aspects, but form what i have heared
that should be fixable.
this commit might create some unused code, that shall be cleared,
especialy i want to remove random.hpp/cpp, rng.hpp/cpp
add from_side check for require_random

"from_side" is an attribute whose only purpose is to enable a check by
the server that a package is really sended by the side given in
"from_side", if thats not the case, the server sets an attribute
"side_invalid". The main purpose of this contruct is to disallow
cheating in mp.
adding wesnoth.is_synced() #21697
removed unused rng code.

i also replaced set_random_results/get_random_results with
synced_checkup in recruit_checksums in create.cpp.

i don't see a reason why we shouldn't use the checkup when calling
place_recruit from wml, since the wml is called on all clients. Just
like a normal recruit. (if we are in an unsynced context then checkup
doesnt have any effect anyway.)
record moves before entering the synced context.

ater this we also don't use undo stack for attacks in replay.
stop replay when we have reached the end.

the old code used to execute one last [end_turn] after the end of the
replay was reached, This doesn't work because the wml might require
[message][option] or similar during "turn end" events and we don't have
the data for that.