This fixes the problem where we already have messages and then have to
sort again.

This changes the ui to show the spinner while we are sorting. It only
shows one line of the spinner since there are an unknown number of
messages at this time.

Updates to a store can be asynchronous so we shouldn't select it just
because it had an update. Selection of the stores should be driven by
explicit user commands.

This fixes an issue with the updated count logic, where only fetched messages
where counted to the exists string of the rue count.

Note that the count is still broken (we only count read / unread messages we
fetched, but that is the same behaviour as prior to the commit
66b68f35b3f3f3b97ec9951397fd75afeb0d0995)

Using mouse scroll before messages load will trigger a panic as
`ml.store` has not been assigned yet and is `nil`.

This reverts commit bd4df530095ee343778a59120a9e641c01010b0f.

I did not properly untangle the opening / dirlist update of each other.
This interferes with the imap worker, hence the revert

Currently the dirlist ignores the counts provided by the dirInfo.
However some of the workers can actually provide accurate counts much quicker
than if we count the flags.

Eventually we will also want to enable displaying counts for background folders,
where the brute force counting won't work as none of the headers are fetched yet.

This commit models it in an opt-in manner, if the flag isn't set then we still
count the messages manually.