Speed up playlist restoring by moving sqlite query off main thread

The playlist fetching uses QtConcurrent to make the playlist on a
different thread (possibly concurrently for each item).
However, profiling reveals that the slow operation is fetching
the rows from the SQLite database, making this redundant.

Instead move the whole playlist loading, including the database access,
into a single function, and call that function in a different thread via
QtConcurrent::run.

This has the side effect of moving all the concurrent stuff from
PlaylistBackend into the callers.

kstartperf measures:

Before: 7.5s cold
        3.6 s warm

After: ~4.0 s cold
       3.5 s warm
Avoid db commits during startup

When starting clementine, each playlist is loaded in turn.
When loading a playlist, the new tab order is committed to the db,
but we don't need to do that here because we know that once all the
playlists are loaded the tab order will be the same as it was initially.

This speeds startup substantially.
kstartperf:
Before: 3.5s
After: 1.5s
Do Podcast updates on song change off main thread

Each time the song is changed, the podcast backend checks whether the
new song is a podcast and, if so, mark it as listened to. This requires
1-2 db queries, so do it off the main thread.

Time to change song before: 300 ms
                    after: 50 ms usually, 80 ms sometimes
Merge pull request #4644 from sbird/fasterstartup

Patches to start clementine faster