Do not issue a duplicate LIST for the top-level mailboxes

When a GUI is attached to the models, Imap::Mailbox::TreeItemMailbox::rowCount
will get called immediately as a result of the GUI which is willing to set up
the view headers and similar stuff. This results in instantiating the
DelayedAskForChildrenOfMailbox, and when the event loop gets a chance to run,
this will ultimately send the LIST command.

However, even before that happens, the model switches itself online via a
(queued) call to setNetworkOnline. This code would previously detect "ah, we're
reconnecting after being online, so let's refresh the list of mailboxes". Again,
this queues the DelayedAskForChildrenOfMailbox, but this time with a special
flag "issue LIST even if it's fresh already". It also flips the m_netPolicy to
online because we're, well, online already.

Now it is time that the first DelayedAskForChildrenOfMailbox to come into
action. It notices that its persistent index is invalid, but it shouldn't matter
because it knows that it's to ask for a top-level mailbox which is usually
represented by an invalid index. So a LIST gets sent.

After a short while, the second DelayedAskForChildrenOfMailbox is triggered. It
cannot even check whether the children of the root mailbox are already being
loaded -- they are, but the class was explicitly flagged with a special "refresh
this no matter what is in the cache" flag. Fair enough, the code for checking
the m_fetchStatus is not there (and it looks like a good reason to me), so a
second LIST gets sent.

There are couple ways out there. The Delayed... could be modified so that it
does not actually talk to the Model at all if the LIST is already on its way.
However, this change is simpler, it prevents creating the second Delayed...
instance and therefore it looks like a better fix to me.

v2: addressed Caspar's comment

REVIEW: 112503
Model: emit messageCountPossiblyChanged when periodically invalidating the message counts

The code which takes care of periodically refreshing the view of mailboxes emits
dataChanged() whenever it invalidates the cached message counts for a particular
mailbox. The systray code was, however, only listening to the
messageCountPossiblyChanged signal. During normal operation, this is not an
issue because the GUI's views would intercept the dataChanged and ask for the
actual data, which triggers an IMAP STATUS which in turn updates the message
counts and systray therefore notices that the numbers might have changed.
However, when the views are hidden for some reason, this process does not happen
and the systray icon is not updated.

CCBUG: 324309
REVIEW: 112474