[mkcal] Make ExtendedStorage dependency on base KCalendarCore::Calendar.

[dcaliste]

This would allow to later create new calendar based on SQLite
backend, without inheriting from ExtendedCalendar, but only
based on upstream KCalendarCore::Calendar.

This is a follow-up of #23, with only the MR making the switch in ExtendedStorage from ExtendedCalendar to KCalendarCode::Calendar. For the tests to pass, it requires to compile KCalendarCore with https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/98 for the moment.

It is also introducing the following changes in ExtendedCalendar though:

• ::addEvent(Incidence::Ptr) is now adding an incidence without specifying a notebook (previously it was assigning the added event to the default one).
• ::addEvent(Incidence::Ptr, QString) is now using the default notebook when the QString argument is empty (previously, it was failing with a warning).

The rational for the change is the following: upstream has no support for addEvent() with two arguments, it is first adding the event and then calling setNotebook(). So we need a way to add incidences without notebook. That's the role of the overloaded method. While the new 2 arguments method is dedicated for event with a notebook, defaulting if necessary.

I've modified tst_load to mix ExtendedCalendar and KCalendarCore::Calendar as calendar support for a SqliteStorqge backend. With an upstream calendar backend, we see that we have no other choice than adding calls to setNotebook().

Hopefully these changes will not affect too much real code since we use the 2 arguments method in almost every cases. But the case where we were expecting the default calendar, we will need to add a call to setNotebook(), or use the 2 argument variant with an empty second argument.

@pvuorela, what do you think ? This may have quite unexpected consequences, but maybe the change is worth to drop the ExtendedCalendar dependency.

[pvuorela]

Not entirely sure. The addEvent(Ptr) did make some sense by adding it to default notebook. In kf5-calendarcore the whole concept of default notebook is now peculiar, nothing seems to be using it. And then again, if it's valid to have incidences without a notebook, wouldn't it then be consistent if addEvent(ptr, string) with an empty string also had the event without a notebook. Perhaps more error prone, but consistent with such concepts.

Having said that, I do acknowledge that plain addEvent(Ptr) is not used widely on sailfish.

upstream has no support for addEvent() with two arguments,

Though should it?

Good thing here is that the changes are not big. Maybe we could keep this PR open for now and consider inclusion if the ExtendedCalendar inheritance skipping materializes into something.