don't block gui thread on status bar updates

| thy shalt not block the gui thread

This completely rejiggers the way the statusbar text is built Statusbar text calculation was previously a fairly cheap operation that was done blockingly. Alas, last year the computation was equipped with a recursive stat job but still kept blocking. This meant the entire gui thread was at the mercy of the stat job's performance. It could finish within nanoseconds, or milliseconds or seconds. Welcome to the brave new world of multi second gui stutter :|

Dealing with this was a right mess unfortunately. View now has yet another async property to replace the blocking getter. Callers now place an update request, which does essentially what the previous function did but instead of blocking on the stat it connects it to a slot which does the other half of the previous function.

I've also reorder a lot of the code to get less nesting and tighter variable scopes.

The previous calculation tech has also been replaced with a helper object that acts as both item counter as well as context carrier to bridge the scope gap between update request and actual update of the string member.

Known slow items will now additionally skip the stat branch entirely and instead return to the previous behavior where only the items in the model were counted.

All in all this removes intermittent GUI lockups opportunity from this call chain.

On network'd file systems such as smb and sftp this now additionally returns the update performance to before the introduction of the stat (i.e. back to nanosecond speeds) and by extension removes excess network traffic caused by the stat.

In numbers: before this diff dolphin would intermittently lock up for 1.4 to 1.8 seconds on fish:// connected over slow tubes to a HDD. It now does not lock up at all.