Bugfix/git shortcuts

Hello,

After installing Git with Chocolatey, I was quite disturbed by the fact that its various shortcuts were not installed by default. As I believe that such a behavior is not an acceptable default setting for the masses, here is my pull request containing the related changes.
> Perhaps we look at the packageparameters pattern? https://github.com/chocolatey/chocolatey/wiki/How-To-Parse-PackageParameters-Argument

As a [Nix](http://nixos.org/nix) and [NixOS](http://nixos.org) user, parameterization and default configuration of package deployments is a very important subject to me :stuck_out_tongue_winking_eye:

Parameterizing a package may be an option but it must not be made without being aware of the consequences: the more states there can be, the more maintaining work you will have to provide.

_The following answer is adapted to the current Chocolatey status and only implies changes on the git* packages. I do not consider it to be the best solution on a very long term._

IMHO, there are three main use-cases for git:
1. To be used from the CMD only.
2. The dependency of an higher-level tool (e.g. posh-git, SourceTree, GitHub).
3. As a complete suite including UX improvements by using a tighter OS integration.

To be honest, I believe that if we only have to chose one use case, 3 should be be the way to go.

1 & 2 can be the same low-level package (I will call it `git-core` to simplify) because they implies the exact same requirements. However, because of conflicting needs (see the paragraph below), using package parameters would require that 3 should be either respected with:
* An higher-level package depending on `git-core` which ensures that the additional components are installed and available to the end-user.
* Another package (=a derivation of the default one) installed side-by-side with `git-core`.

##### The issue when using a package with options as both a dependency and an end-user application / why I believe in other approaches
A package `pkg-low` is being used as a dependency by another package `pkg-high`.
```
pkg-low
   |
pkg-high
```
Because most of the end-users of `pkg-high` do not have reasons to use some optional features of `pkg-low`, `pkg-low` has been coded to not include these by default.
If an end-user of `pkg-low` wants to use an optional feature, he must trigger a specific parameter when installing it, thus asking for a `pkg-low'` state.

Now let's confront those 2 facts together.

Suppose that an end-user firstly wants to use a `pkg-high` feature and installs the package with `choco install pkg-high`.
Later, he would like to use a feature only available with `pkg-low'`.

With Chocolatey, this end-user would then have to:
1. Uninstall `pkg-high`
2. Uninstall `pkg-low`
3. Install `pkg-low'`
4. Install `pkg-high`

```
pkg-low     pkg-low     pkg-low'    pkg-low'
   |     ->          ->          ->    |
pkg-high                            pkg-high
```

I can conclude that the number of required steps to switch from one state to another increases in-pair with the number of possible derivations (made available via PackageParameters) and packages involved in the dependency tree.