Manually throttle Bookmarks workload more closely

On lower-end machines it's possible to overload the machine with calls to hg/git because of the way GCD interprets calls which it considers to be blocked on I/O.

SourceTree schedules all of its work through Grand Central Dispatch, which deals with thread pools based on the number of CPU cores available. This should mean that things are scaled appropriately based on the machine, however it was revealed to me in a lab session that GCD is a bit smarter than that - it detects if any of those threads is currently waiting for file I/O or similar, and if so fires up another thread to deal with the next request in the mean time. Unfortunately, calls to Mercurial are seen like this, so GCD goes beyond the 2-4 threads and starts firing up new ones to service more Python calls. On a low-end machine the hg calls probably don't clear quick enough, and this becomes a snowball effect (the 2GB starts to run out, making each hg call slower, which means GCD thinks they're blocked on I/O more so launches more threads etc etc). You just don't see this on other machines (and I test on my wife's 5-year old Core Duo MBP, but it has 4GB and the hg calls seem to clear quick enough for the pile-up not to happen).

The main culprit here is likely to be the bookmarks window, although in theory any view could trigger it with enough queued work.

Unfortunately to maintain 10.6 compatibility we can't just use a custom dispatch queue set to concurrent (only serial custom queues are supported in 10.6, and those serialise things too much - on testing this the bookmarks window feels interminably slow). The better option might be to monitor the number of outstanding calls in the bookmarks window much like the Hosted Projects window and limit it to queueing a max of (say) 3-4 to GCD at any one time.