Enhancement in parameters 'h' and 'H' to define custom headers, plus issue #12 fixed.

### Enhancement in params `h` and `H`
Now optional parameters `h` and `H` no longer do the same. There's a subtle differente between them. If the specified HTTP header doesn't exist, both behave the same, sending that custom HTTP header with the request. But when the header exists, ´H´ will replace it with a user-supplied value, while `h` will add a new header regardless another header with the same name exists or not.
#### Example
By default, hydra will send an HTTP request like this:
    GET / HTTP/1.0
    User-Agent: Mozilla/5.0 (Hydra)
    Host: 127.0.0.1
Insted, if we specify ´h=User-Agent: Mozilla/5.0 (Google Chrome)´, the request will be:
    GET / HTTP/1.0
    User-Agent: Mozilla/5.0 (Google Chrome)
    Host: 127.0.0.1
    User-Agent: Mozilla/5.0 (Hydra)
And if we specify ´H=User-Agent: Mozilla/5.0 (Google Chrome)´, the request will be the following, effectively replacing the user agent:
    GET / HTTP/1.0
    User-Agent: Mozilla/5.0 (Google Chrome)
    Host: 127.0.0.1
This feature turns to be really useful in two scenarios: when user wants to customize the user agent and when the form being attacked is being guarded by a CSRF token. These tokens are usually linked to a cookie placed the first time the user visits the webpage, and are usually placed in hidden form fields. In order the brute force to be successful, one must visit the webpage first and gather the CSRF token and the cookies placed by the server, and reply those cookies from hydra, instructing hydra to use those cookies always (via `H=Cookie:...`), since a new request with no cookie header will cause the server to issue new cookies therefore invalidating the user-captured CSRF token.
`hydra 127.0.0.1 http-form-post "/test.php:user=^USER^&password=^PASS^&token=<my_csrf_token>:H=Cookie: <my_cookie>" -L users.txt -P passwords.txt -w 30 -v`

Therefore, the enhacement I proposed in issue #11 is now obsolete since with this feature, I consider it to be nonsense. I recommend to close it since it is no longer needed.

### Issue #12 fixed
Issue #12 has been fixed, and now cookies that specify no path are correctly retrieved.

### Limitations
I have noticed a poor handling of the HTTP `Location` header, and more complex webpages that redirect the user after successful logins (such as the Joomla CMS), are incorrectly handled by hydra, and in other simpler pages, redirects make hydra slow. I recommend rewriting the HTTP protocol handling code, using, for instance, Apache's libapreq library, and to do some research in why hydra slows down when handling multiple redirections. I'll be working on that in the following months and if the results are satisfactory, I'll let you know.