remove a useless argument in play_replay

video is ignored, it is always obtained from display
Add the "core" command line option.

This option specifies a [core]'s id which is to be loaded.
Not used yet.
Set the core_id preferences item at game launch.

The id of the used core is set and saved if given as a command line
interface.

This commit makes use of the new "core" command line option.
Add no_addon item to the game_config:: namespace.

This will be used to switch addons off during runtime.
Used for fallback if loading fails.
Can later be used to give gui controll over loading the addons.
Load addons based on game_config::no_addons instead of command line.

This is to make sure that we can change the loading of addons at
runtime.

Can be used to provide a fallback solution.
Removed the core file path from the preferences.

The new implementation works with the id only.
Made the "broken" core less broken.

This makes sure that the broken core fails at loading and is not marked
as invalid during its config validation.
Redesigned the core loading procedure.

Cores are now validated, invalid ones are discarded.
The failsave mechanism now tries to load without add-ons in case of a
fail before it falls back to the default core.
Core definitions are now read from a cores.cfg in every add-ons'
toplevel.
Propagate the noaddons command line switch value to the game config.
Don't ignore noaddons commandline opt in game_config_manager

When the unit tests are running, the game_launcher, game_config
code is never involved, so the noaddons cmd line opt cannot be
ignored. This commit makes it so that regardless of game_config
value, the --noaddons command line flag is respected.

This reverts commit 7fd093d7c0bb425756ca3faa01798c67d9bc8cba.
Changed the output form err to log for merging terrain.

In case the same terrain definition had to be merged into a editor group
it already was in the issue was reported to the error channel.

The issue should only be a normal thing to happen thus I reduced the
severity of the output.
split off terrain data caches from the gamemap object

This commit splits some of the functionality of the gamemap object
into a new class, the "terrain_type_data" object. This class is
intended to hold a record of known terrains and the terrain code ->
terrain type map. It handles merging in new terrain definitions,
and it is shared between map objects. It is also cached by the game
config manager, so that we only recalculate this data when we
change configs.

There is in fact a *semantic* change going on here, which is that
when a scenario introduces a new terrain type by merging, this gets
added to the global cache. The alternative is to make a copy of the
global cache, only for the this scenario, as soon as we have to
dirty the cache. However since I didn't see any downside to putting
the merged terrains together and carrying them across scenarios,
I opted not to do that here.
use the game config manager's terrain cache in play_controllers

this completes 1a4efb6b22aeb0742c9083a7d0515ebdef799078 by
passing a reference to global terrain data cache to these
functions
lazy computation of terrain type data

This preserves the way it was done previously, where we wouldn't
scan for terrain data until we actually load a map. This reduces
the wait you must endure when you click "campaign" or "multiplayer"
at the titlescreen.
cache minimap images in mp create screen

When we are actually in the game, the image.cpp file uses an
elaborate collection of caches to make sure that all images are
cached and reloaded rather than redoing work (even scaling). It's
questionable whether the amount of caching going on there is
appropriate, it seems it might even be faster if we did less. But
one place that we don't do any caching and performance is bad is
in the mp create screen. There was a bug report in 1.12:

https://gna.org/bugs/?func=detailitem&item_id=21801

In this commit, I implement quick and dirty caching for scenario
minimap images. Each scenario record holds a surface (an SDL
reference counted pointer to image data), and when a minimap is
rendered this gets saved, along with the md5 hash of the map that
got rendered. Whenever a minimap is requested, we hash it first
and check if the cache is dirty. If so we recalculate, otherwise
we return the cached image.

The code is also cleaner and a bit less convoluted than the
previous code -- the previous author seemed to think that surfaces
are "object" types and not "pointer" types, that require an
additional layer of memory management with boost scoped pointer
etc. This was in fact redundant.

I don't know if this commit will actually help report 21801,
the profiling seemed to suggest that it's the minimap rendering
code that is actually slow. But it seems that this can't hurt,
and may at least mitigate the slowness, since except for random
maps it means the minimap calculation won't be repeated.
Merge pull request #328 from cbeck88/fixup_terrain_caching

split off terrain data caches from the gamemap object
Merge pull request #327 from cbeck88/add_map_image_caching_to_mp_create_screen

cache minimap images in mp create screen
Update Xcode project file
fs: Fix normalize_path("") incongruity with Boost.filesystem

The non-BFS version of normalize_path() returns an empty string when
passed an empty string, but the BFS version returns the normalized
version of the current working dir for the Wesnoth process.

Due to the way editor::start()'s arguments are built from the process
command line, the result of normalize_path("") gets passed to it when
starting with the --editor switch and no map path argument. If the
result describes a directory, the editor brings up the filechooser
dialog on that path; otherwise, it attempts to open it as a map file.

Making the BFS version of normalize_path() follow the non-BFS behavior
fixes the editor unexpectedly bringing up the filechooser when started
from the command line.
Fix spelling in comment.