WIP: Refactoring

It's not only refactoring I added some other parts too. I'll go make animated gifs for better visuality now. :dancer: 

## Non git-repositorys
![gifrecord_2014-06-11_130346](https://cloud.githubusercontent.com/assets/5219415/3243457/6de42bf8-f158-11e3-8cfd-6771ed18d832.gif)
It only shows the commands when we actually are inside a repository. If that is not the case it offers to `git init` one. ~~Has some inpact on performance, package activation takes ~60ms for me. Do you have a method to only show the commands if necessary and still make use of `activationEvents`?~~

### We now have our own git-plus palette. Problem solved. :dancer:

## Stage/Unstage files with multiple selections
![gifrecord_2014-06-11_132011](https://cloud.githubusercontent.com/assets/5219415/3243565/88fe5fd8-f15a-11e3-9c7b-ff6db80778e0.gif)
I _really_ like my multiple selection views. :wink: 
On the right side it displays the git porcelain status for that file, `?` being `untracked` in that case.
* [ ] They need a "nothing to (un)stage here" message!

## Stage Hunks
![gifrecord_2014-06-11_132336](https://cloud.githubusercontent.com/assets/5219415/3243581/f8948c50-f15a-11e3-8829-7be43590c3e1.gif)
Now _that_ is my baby. It allows you to selected a file with unstaged changes and stage individual hunks from it. 
* [ ] If theres only one hunk, immediately stage it?
* [x] Maybe reduce the context shown for the hunk? It's 3 lines (default) at the moment but that gets unusable really quick.
* [ ] Unstage hunks? I don't even know if thats possible but it would be cool!
* [ ] They need a "nothing to (un)stage here" message!

## Checkout All Files
![gifrecord_2014-06-11_133450](https://cloud.githubusercontent.com/assets/5219415/3243666/816fb404-f15c-11e3-8418-7ec17ddffd95.gif)
Should be self explanatory.

## Cherry-Picking
![gifrecord_2014-06-11_164337](https://cloud.githubusercontent.com/assets/5219415/3246724/01bb38d8-f17e-11e3-9032-f66ed35aec09.gif)
I might need to introduce some kind of sorting to the commits. I think it would be best if the commits would be cherry-picked chronologically, oldest first? Or does it not make any difference for git?

Fuzzy filters for the __hash__ at the moment, I thought it would be nice if you already had a hash to pick. Or would the commit subject be better? Might be able to teach the fuzzy search to search for both, I'll dig myself into it. :wink:

## Under construction:
* [x] Git Path configurable
* [ ]  Close open files on checking out other branches
* [ ] Stash
* [ ] Merge/Rebase
* [x] Cherry-pick?
* [ ] Specs - They make me headaches, specing asynchronous functions is not a nice job, especially since we can't use the jasmine helpers on the atom BufferedProcess!! Oh well...
* [x] The git commands are... not up-to-date. Variables? Async Problem?
* [x] Git Diff: No currentFile -> Diff All.
* [ ] Central utility for currentFile/dir() and other abstractable things.
* Open for ideas. :wink:
might want to check if atom.project.getRepo() returns null obj before using it.