use synced_context: change get_user_input

previously and afterwards there can be 2 ways an action(attack, rectuit, move...) can be executed, the first way is that the action runs on the local client, and the action is sended over the network as soon as it is completed, this happends in recruits, moves, recall, and some more. The second way is that the action is sended over the network first and is then executed on all cielents simultaniously, this happends in attck events, and similar happends in prestart/start events. This is also why mp_sync didn work in this actions before: side 2 noticed that it needs datab from side 1 but side 1 did send the execeution of the action before it generated the user_input data. That's why side 2 doesnt have the user input data at this point. Previously there was one special and very bugged case when the code waited for remote input before calling get_user_choice: [get_global_variable].

This commit moves the "waiting" from persist_var.cpp into get_user_choice so that the caller of get_user_choice don't have to worry about it. With this we can also use get_user_choice if we already sended data over the network. And we can enable the mp_sync in attack related events and prestart events. This is the commit to fix http://gna.org/bugs/?20871.

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.
add functions in replay

these functions might already be used during a sooner commit in synced_context.cpp.
use synced_context

these commit uses the synced_context in replays in and in attacks.
we also don't need to use expected_advanaments anymore, because advancements now run through get_user_choice.
Which was not posible before, because get_user_choice didn't work during attacks.

 the main intention of these commits 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 these commits (try to) unify 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.
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 durign 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 vilibility wansn't calculated normaly 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.
use synced_context in recruits/recalls

i think i should use run_in_synced context for recalls, idk why i didn't do it...
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
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