use synced_context in moves

In order to get the same move results that we got during the game in replay, we now save continue_move/skip_sighed in the replay.
We also call move_unit now with replay_dest = NULL, is_replay = false during replay.
So during replays we now execute the same code, that we execute during the normal game. That also means that, the variable replay_ in move.cpp is now always false. which means there is some unused code now in move.cpp
i still hesitate to remove this code because it somehow seems to be too easy to do it like this, but i have found no bugs.
i suppose, that is_replay_ if a leftover from a time when visibility wasn't calculated normally during replays.
in a later commit i also put skip_ally_sighted in the replay data.

I don't use run_in_synced_context for moves because some methods use the returnvalue of move_unit. Instead i splitted move_unit into move_unit_and_recod and move_unit_from_replay, because using 'if' isn't possible for set_scontext_synced. And i don't want to record a move if nothing happend. Also i think a very small code duplicate for one 'if' less is a very fair trade.

this commit is part of pr 121.
use synced_context in recruits/recalls

i don't use run_in_synced in recalls becasue i dont wan't recordings when the racall is invalid.
add third argument to recorder.user_input

the third argument is from_side which is part of a contruct to prevent cheating in mp.
remove unused replay.cpp::type_by_index
use synced_context in undo and rest

in undos we have to do it differently in different actions becasue in moves we just show the move (ro save performance i guess) but in other actions (recall/recruit) we also fire the events again.

"Rest" means: lua_ai, disband, fire_event (right click menus), update_shroud manualy.

this commit is part of pr 121.
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.)
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.
bring back unit_advancements_aspect

by moving code from synced_commands.cpp to actions/attack.cpp so that it
can be directly called from ai/actions.cpp
removed unused code
added a check for unit's destination in moves
correct the value of pos_ in replays.
rearrange comments and debuglogs
add skip_ally_sighted to replay

because this can affect the result of a move, we need this data in the
replay.
add comment in replay.hpp
removed unused code
implement the deterministic mode for sp.

the player can now choose whether he want to play a new SP game in the
deterministic mode where he'll get the same results when he reloads a
game.

i don't really know much about the gamestatus cpp/hpp file, so i just
copied from the difficulty code (to create the random_mode attribute).

i think it would also be nice to enable the deterministic mode for MP
but i currently don't know enough about the mp connect code to that.

this commit also contains a correction in the random_calls checkup which
should have been in another commit.
a third argument for lua wesnoth.synchronize_choice

luas sync_choice now takes a third parameter which is a array of number
that determines on which sides the function will be evaluated, if you
use this parameter you'll also get a table back, the passed function
will then be executed on all passed sides simulaniously (you don't have
to wait for the other side before you can make your input) example:
[code]
[event]
name = "start"
[lua]
code = <<

local result = wesnoth.synchronize_choice(
function()
local option1 = T.option { message = "No", T.command { T.set_variable {
name = "input1", value = "No"}}}
local option2 = T.option { message = "Yes", T.command { T.set_variable {
name = "input1", value = "Yes"}}}

wesnoth.fire(T.message{ message =  "Are you sure you want to play this
game?", option1, option2})
return { value = wesnoth.get_variable("input1") }
end,
function()
return { value = math.random(30) }
end, {1,2})

wesnoth.message("Player 1 wants to play: " .. result[1].value)
wesnoth.message("Player 2 wants to play: " .. result[2].value)

>>
[/lua]
[/event]
[/code]
note, that wesnoth is still a turn based strategy game and it's most
likeley a bad idea to require user input from sides when it's not their
turn because they might be afk.
so it might be better to use it during [start] events

we replace lua_settop by lua_pushvalue because we want to be able to
call the function multiple times in case one controller controlls more
than one of the passed sides.
removed unused replay_source_manager