Subscriptions in database: UI

[rfc2822]

• AddCalendarActivity creates Subscription in database instead of a local calendar
• CalendarListActivity lists Subscriptions from DB instead of local calendars
• EditCalendarActivity edits Subscription in database instead of local calendar
• + all related fragments

Regarding permissions: we now don't have to ask for calendar permissions anymore in order to be able to create (manage) subscriptions because we have them in our DB. So I'd change the permission logic as follows:

• As soon as there's at least one subscription, show some UI element in the CalendarListActivity that calendar permissions are required for synchronization. Users can then give the permission.
• Permissions don't have to be checked elsewhere in the UI.
• The synchronization worker has to check calendar permissions. If they're not granted, it should show a notification that leads to the CalendarListActivity.

Depends on #76

[github-actions]

This PR/issue depends on: * #76

[rfc2822]

@ArnyminerZ I suggest that we do this activity per activity. CalendarListActivity or AddCalendarActivity could be good starting points. Which one do you want to start with?

After each Activity I'd like to add a review/do amending commits and then we can continue to the next Activity.

[ArnyminerZ]

I'll start with CalendarListActivity since it's only a "display" and it seems quite simpler. Then I'll handle permissions, which means removing the starting request, and requesting them just when synchronization runs.

Then I'll work on AddCalendarActivity and finally EditCalendarActivity

[ArnyminerZ]

By the way, we should really suspend all the functions from the dao just to make sure we don't call them from the UI thread, or errors like this will be thrown:

java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long period of time.

[ArnyminerZ]

[rfc2822]

Should be finally done :)