Cache git projects, and more optimizations

[jccr]

Fixes #41

Before:

Notes:

• The git projects were found again every time the view is opened.
• Loading the items happened on the UI thread, a68d82ba9bb5f9c50a124938cd9b52957e203e29 was a good attempt but it needed to be on a separate thread. Using Atom's Task to accomplish this.
• Anytime you type to filter down the list the git-utils::getStatus() and git-utils::getShortHead() functions would be called again for each list item because the item views were being unneccessarily recreated.
• The git getStatus call is expensive on large projects with a dirty index

After:

Notes:

• Git projects are found and loaded on a thread separate from the UI thread.
• Once they are loaded the git status states are lazy loaded for each item using separate Tasks.
• After the projects and status states are fetched then it is cached for the next time you open the view
• The next time you open the view it opens using the cached data right away, and in the background it starts the loading process again to refresh the data.
• Typing into the filter box doesn't trigger unnecessary item view recreation anymore.

It would be nice if this code could be cleaned up further, and a more comprehensive spec added to cover the new caching features. (I got stuck when thinking about how to create the spec)

[prrrnd]

Wow, that's awesome! :+1: I am going to look at it in details as soon as I have some free time - probably this weekend.

[jccr]

@prrrnd Thanks!

I've pushed a few more commits that might help out with some issues I have encountered so far:

• git.open needs to close things with repository.release. If not then the OS complains about too many files being open, and memory leaks and so on..
• Too many tasks running in parallel that are reading the info of many many git repos would pretty much freeze my system for a while. I added in a "task pool" to throttle them down. The number of tasks that run at once is based on the number of cores of the client, or we could use some pre-defined value.
• isRepositorySync was the next part that would prevent the project view from popping up as soon as it could with the cached data. I didn't want to introduce a callback/async mechanism here just yet. I instead went for a more trivial (and hopefully less expensive/quicker) check of the existence of a git repo.

[prrrnd]

Hey @JCCR, I have looked at what you did in more details, and I have to say, it's pretty impressive. Good job! :+1: I don't have much more to say, it seems pretty neat to me, and that's a really great improvement in general. The only thing I see that could perhaps be slightly improved is how the size of the task pool is defined. What do you think are the possible options / how could we define a decent value? Are you still working on something, or do you want me to merge now?

[jccr]

@prrrnd Whoops, I must have left that in while testing. The reassignment to 3 shouldn't be there. I'll fix it.

Oh and no I'm not working on something, I think it looks good to me as well. Thanks for looking it over :)

[prrrnd]

Awesome, thanks! I'll merge now :)

[zargony]

It's so much more fun to use now. Awesome, thanks!