Include images in profile

This adds an entry to the dive list context menu to load images. The user
can select image files and set a time offset to align camera and dive
computer clocks.

Using the exif time stamp the images are tried to match to the times of
the selected dives (with a grace period of an hour before and after the
dive).  Upon success an event of type 123 is created per image with the
string value being the path to the image.  Those images are displayed as
thumbnails in the profile. If the matching dive does not yet have a geo
location specified but the image provides one it is copied to the dive
(making the camera a poor man's companion app).

This patch includes easyexif https://code.google.com/p/easyexif/ which is
originally under a New BSD License to parse the image meta data.

This commit includes a new test dive dives/test31.xml with a matching
image wreck.jpg to try out the functionallity.

Obvious to do's:
Have images on the map
Have the images clickable
Have a proper picture viewer
Give visual reference for image time shifting.
Use the new profile

Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Move save of preferences to the preferences dialog.

I had a few very strange bugs regarding to preferences (like clicking on
apply twice so things worked), because the code that moved from
"QSettings" to 'Internal Settings Struct' was being triggered on the
mainwindow, *after* the settingsChanged signal was emmited. This should
fix the problem.

Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Save the old pref system when changing the new one

Since we have now a mix of old / new prefs, remember
to change both when we alter something.

Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Load options as soon as the progrm starts

Populate the status of the profile tool box as soon as the program
starts.

Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Remove a lot of unused code.

This will probably be added back in the future, but for now
they have no use and it was making me nauseaus.

Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Process events just after starting the StateMachine

This is needed because of a braindead issue on the Qt event
loop:

http://stackoverflow.com/questions/10059721/qt-qstatemachine-sync-problems-initial-state-not-set-on-started-signali

For the "event 1" to be received, the machine must already be
in a state that react to that signal. Even it was a queued
connection, the slot would be queued but only after the signal
 was received, which it isn't since there is no connection
yet at that point.

To solve your problem, you can wait for the machine is in
"state A" before emitting the signal:

machine->start();
qApp->processEvents();

Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>