fix savegame reading.
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.
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.