blindfold is removed when control of a side is received

in blindfold_ii, blindfold was taken off when local side takes control
in this fixup, blindfold is taken off as soon as host gives control of
any side.
to achieve this, playturn.cpp must be able to ask the playcontroller to
remove the blindfold.
we create a virtual method of play_controller, on_not_observer,
which is called whenever this client gets local control of a side
(it becomes ai or human)
on all play_controllers except play_mpcontroller, this does nothing
in play_mpcontroller it calls a "remove_blindfold" function
when a human side takes control, remove_blindfold is still called,
as a precaution.
apply a brief blindfold when changing sides in hotseat mp

Fix bug #3865: While the turn dialog used for changing sides is active,
apply a blindfold, which is removed when the dialog is cleared.
ai_helper.get_closest_location(): fix bug with tags in SLF

The way how the Standard Location Filter was dealt with only worked
with keys, not tags.
Messenger MAI: fix bug with escort units blocking the messenger

When there were lots of escort units, they previously quite frequently
blocked the messenger’s way, preventing him from making progress even
when it was possible.  Escort units now specifically move out of the
way if they do not need to attack enemy units in the messenger’s way.
Messenger MAI: allow several messengers to be controlled by AI

For two of the CAs this mostly just means reading the [filter] tag and
picking one of the messengers.  However, for the CA moving the escort
units, it means a complete rewrite, as the AI now needs to figure out
which escort unit should be moved toward which messenger.
Messenger MAI: add optional invert_order= key

In the default configuration, the AI moves the messenger which has
advanced the furthest through the waypoints first.  If this key is set,
the rearmost messenger is moved first.
MAIs: minor code simplification in AIs that take both [filter] and id=

These are the AIs that used to use Behavior Candidate Actions (BCA).
Patrol MAI: fix bug with save/load persistent data storage

WML values may not be used as keys, this can make savegames invalid.
Store information in the units now rather than in self.data. (Note:
storing in self.data would also be possible if the syntax were changed.)
fixup b854aab437f157eea642131b882a4987a95c5b6b (ai side drops)

logic error was introduced in client side controller types:
when a player drops and controls an ai-side, the side_drop signal
is only sent to the host, who should make that side a local ai,
not a networked ai.
don't show petrified units in "Damage versus:" tooltip

since we can't attack these, this information is not useful.
afaik it is quite common to have permanent "statues" in MP maps,
and extremely rare that units may be unpetrified in any core or
umc scenarios.
update changelog
updated Slovak translation
updated Hungarian translation
Mark Wesnoth not high-resolution capable

Greatly improves performance on retina devices
Remove references to unused flag ENABLE_OPENMP_SUPPORT

Not available in clang, gcc support unstable in versions available in
Xcode. Defaults to no
Compile Lua with OS X options

Avoids some warnings, more secure
optimize minimap.cpp

moved 2 preferences::.. calls out of the loop so that we just call it once.

the following is especialy true on large maps, all results are recorded from a msvc 2010 release build, and recorded with the msvc 2010 sampling Profiler.

these calls are less expensive than the final scale_surface_sharp call at the end of the funcion. But if you assume the scale_surface_sharp woudn't be there, then they'd use a major part (~50%) of the cputime of get_minimap.

i also tested replacing scale_surface_sharp at the end of the function with scale_surface. Here are the results:
tested on LotI Mp Map (part of LotI addon) which has a size 200x200 with fog but no shroud, no logs, ingame debug mode enabled (the :debug wesnoth-console command).
the image on the upper middle is made with scale_surface the other two are made with scale_surface_sharp.
The down-left Image are the profiler results from the scale_surface version of get_minimap, the down-right are from the scale_surface_sharp version. The record was started shortly before a moving so the record only  shows the cputime during moving. Also the content of this commit is used in those testings.
http://i.imgur.com/YETVuNq.png
the profiler shows that during movements (with fog) more than 50% of the cputime of wesnoth is spend in scale_surface_sharp for get_minimap, and i personaly think differences in the minimap are not worth that. But there are different opinions and thats why i didn't change it yet, but i still propose replacing the last call

minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));

with something like: 

if(map.w() > 100 || map.h() > 100)
{
minimap = scale_surface(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
else
{
minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
note, that the 100 is choosen rather randomly.
If that's a problem with msvc then i propose wrapping it in a #if.
I have heared that we will be able to do scaling with hardware acceleration later (around september), but i don't see how thats a reason to not do this until then.
Coward MAI: remove unnecessary condition

ai_helper.movefull_stopunit takes care of this internally.
Return guardian MAI: remove unnecessary condition

We can never get to this point in the code if the unit does not have
moves.
MAIs: test for unit equality directly, not via coordinates