Marble 2.0

Refactoring goals towards a Marble 2.0 version.

Marble Library Split

Split libmarblewidget into several libraries:

libMarbleCore
- Non-interactive classes, e.g. geodata, file parsing
- No dependency to QWidgets or Qt Quick
libMarbleMap
- Interactive, UI toolkit independent classes, e.g. layers, graphicsview
- Dependency to MarbleCore
- No dependency to QWidgets or Qt Quick
libMarbleWidgets
- QWidget related interactive classes
- Dependency to QWidget, libMarbleMap, libMarbleCore
libMarbleQuick
- Qt Quick 2.0 related interactive classes
- Dependency to QtQuick, libMarbleMap, libMarbleCore
Further possible ones (see also plugins below): MarbleRouting, MarbleTours, MarbleMapEditor

The header structure in src/lib/ should match the exported headers in include/. No "flattening" as it happens currently where e.g. marble/geodata/* is copied to /marble/.
During compilation, the subdirectories of marble/ are not added to the compiler search path anymore, so #include statements need to use the full path marble/$module/$class.h for files outside their directory.
Headers follow the directory structure marble/$module/$path, where $path is either a filename or a directory + filename, but not deeper nested

Clearly split between the loading mechanism and the interface (API) such that extensions can be realized both inside a library and via plugins without hassles (emphasis on without hassles)
Deleting plugins should be possible and remove the feature provided by it, but it should not be advertized as a feature
No mandatory plugins (e.g. KML parsing). Mandatory "plugins" must be part of a library
Decide on criteria what to realize as plugins and what as modules (libraries). E.g. only do plugins where a common API is easily identified and at least three plugins of that type are provided by Marble itself