Foreground services

Normal non-foreground [services](https://developer.android.com/guide/components/services) are somewhat downgraded in modern Android versions: there are some background restrictions starting from Android 8, the services can't be started from background (#784), they can be killed by the system.

#931 replaces the service implementation, but still uses the same non-foreground services.

Here are some thoughts on how this should be fixed.

One of the main obstacles to simply replacing non-foreground services with foreground services is the requirement to display a notification. Not only it would be annoying for the user (to see a notification pop up even for short actions), but it also requires to rewrite the way notifications are displayed in the wallabag app.
Another reason against dumb transition to foreground services is the reason that not everything should be handled by foreground services.

In accordance with the docs, foreground services should handle long running *immediate* tasks.
I think in case of the app the only task that qualifies is the synchronization. Maybe also image fetching (or maybe it can be done with a WorkManager job).

Other short actions (like article modifications) should still be handled by background services, which should do fine under normal conditions. If such tasks are blocked by some other background operation (sync), the background service executing them should promote itself to a foreground service (in order to not be killed and lose data).

Some of the tasks (like background sync triggered by schedule or network events) should be done using WorkManager jobs. Now that the task logic is moved out of services it shouldn't be too hard.

For a while in the app the tasks haven't been not explicitly synchronized with each other. The synchronization relies on the fact, that the tasks are executed sequentially by a single service.
Introducing multiple task executors (foreground, background, WorkManager) requires to explicitly synchronize task execution. Maybe an exclusive SQLite write transaction is enough, maybe explicit locks are a better choice, I haven't look into it much yet.

As usual, these are notes for anyone willing to do some development.