reduce overhead of performing repository indicator updates

[shiftkey]

#5310 highlighted that the work to compute the new repository indicators doesn't scale to 100+ repositories. I'd like to review this feature and see if we can address these two goals:

• avoid running the work concurrently (this background work shouldn't steal CPU time from the app or other tools)
• run this less frequently (defer the first run until after the app has settled, and run it less frequently in the background)

[shiftkey]

@iAmWillShepherd and I talked about this a bit today, and it'd be nice to identify scenarios that we know we don't need to fetch here. #1252 came up because an API request is much cheaper than invoking Git to learn that it's up to date.

[shiftkey]

Just realised there was a reason why we ordered the background work to be done fetch first, then loadStatus and #5297 might mean that things are out of sync.

loadStatus also gets the ahead/behind information for the current branch for free, and fetch doesn't surface any information, so doing this in the wrong order now means you won't immediately see the ahead/behind details for your current branch.

I'd like to get a fix for this into 1.3.3 while we're in here refining things. I still like prioritizing status first, maybe there's a way to refresh the ahead/behind details inside GitStore?