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.
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.
fixup some silliness in display.cpp
reduce code duplication in help pages
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
cleanup some of the noise in earlier diff

The decision is to forward more methods of terrain_type_data from
the gamemap object
fixup: fix an assertion failure in titlescreen > help
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.