[mkcal] Move alarm handling to a new class.

[dcaliste]

Also change the alarm setting behaviour.
Instead of dealing per incidence, it is
now clearing and setting alarms per UID.

If an incidence recurs and has exceptions,
all alarms sharing the same UID are removed
and then parent and all exceptions are reset.

@pvuorela , yet another spin off from #61.

In the current alarm code, a KCalendarCore::Calendar is required for two things:

• to get the notebookUid associated to a given incidence,
• to get the instances() list of a recurring incidence, so its next occurrence can be recalculated.

In the context of the coming changes, there won't be necessary a unique KCalendarCore::Calendar that stores the incidences. So I tried to remove it from the alarm API:

• the notebook uid is thus pass in the way of QPAir<QString, QString> where the first element is the notebook uid and the second the incidence uid.
• the instances() are retrieved by a convenient routine that implementers of AlarmHandler are providing. This routine either reread the DB (in the case where we change all alarms of a notebook, as it was done before), or return the full series for a given UID as in memory.

As mentioned in #61, I'm also changing the behaviour to avoid doing per incidence alarm, and move to a per series alarm. In my opinion, this is less error-prone, with less cases to be treated. Just a clear all alarms with this NBUID/UID tuple, reset all alarms for the list of incidence sharing this NBUID/UID tuple.

[pvuorela]

Alright. Let's have this.