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
Add unicode_cast to wrap utils::X_to_Y() functions
Use unicode_cast
Add a ctor to ttexture which loads the texture from a file.
Fix a memory leak in the previous commit.
Merge branch 'master' of github.com:wesnoth/wesnoth
Fix bug #21759

Removed duplicate code that caused timer to be refreshed an additional
time if time runs out. The usual refreshing in
playmp_controller::after_human_turn is already called in this case as
well (after turn ends). The duplicate code gave the bonuses before the
turn ended, and after that the turn was ended (giving turn bonus again)
only if there was no random seed incoming from the server.

Conflicts:
	changelog
make server level_ reflect true start of game position

previousy, the [side]'s in level_ were updated with controller changes,
so that observers who join would be up to date, since controller changes
were not stored in history. we now change this, so that controller changes
are stored in history. they are stored as "[record_change_controller]"
rather than "change_controller" because during a replay we should not
restart the turn and reinit if human changes to droid etc.

this is in preparation to move all controller tweaks to server-side
move controller tweaks to server

(fixup of 736ceaa6c7e81882c9c5b2e932307b1f1ecb3bfd)

following discussion with Soliton, we move all "controller tweaks"
i.e. assignments of networked side to human on the matching client
at start of game, to be server decisions, performed concurrent with
start of game.

in fact the controller tweaks are performed using
game::change_controller, which is modified so that it doesn't try to
make server messages before the game has started.

when the server receives [start_game] from the host, the server will
change_controller for every side, sending corresponding messages to
all players and observers, which will update them as appropriate.
it will also rewrite level_ so that human sides are "network" and
ai sides are "network_ai", making the level_ correct for an observer
who subsequently joins.

we remove the obsoleted client-side code in playcampaign.cpp,
multiplayer.cpp.

We also add to multiplayer_wait.cpp the necessary support code to
interpret [change_controller] messages recieved before game start.