Unix domain sockets

This adds support for unix domain sockets by using a slightly modified version of the unix domain socket adapter from the [docker-py](https://github.com/docker/docker-py) project:

https://github.com/docker/docker-py/blob/master/docker/unixconn/unixconn.py

The modifications are to make the adapter more usable in a greater variety of contexts by getting rid of the context of a `base_url` for the adapter and inventing a URL syntax that allows embedding the socket path into the URL. Basically the socket name goes in the netloc (host) part of the URL, but it's URL-encoded so that slashes become `%2F`'s so that the slashes don't interfere with separating the netloc and path parts of the URLs. This was roughly inspired by URL syntaxes that are mentioned in the following comments:
- http://daniel.haxx.se/blog/2008/04/14/http-over-unix-domain-sockets/
- http://lists.w3.org/Archives/Public/uri/2008Oct/0000.html

So for example if I had a server listening on `/tmp/profilesvc.sock`:

```
$ gunicorn --paste development.ini --log-config development.ini --bind unix:/tmp/profilesvc.sock
...
2014-11-24 16:14:54,943 INFO  [MainThread][gunicorn.error.info][glogging.py +213] Listening at: 
unix:/tmp/profilesvc.sock (95775)
...
```

I can access it as follows:

``` python
import requests

resp = requests.get('http+unix://%2Ftmp%2Fprofilesvc.sock/status/pid')
```

In case you're curious about the motivation for adding unix domain socket support, it was inspired by:

https://github.com/jakubroztocil/httpie/issues/209

Cc: @shin-, @jakubroztocil, @monsanto, @np, @nuxlli, @matrixise, @remmelt


Probably if `requests` had this, docker-py and other projects might be able to make use of it and not have to maintain their own versions. I wonder if @shin- could use this in docker-py.


Very nice @msabramo 


So the fundamental thing to remember about requests is that it is an HTTP library which means we strive to be in compliance with RFC 7230, 7231, 7232, 7233, 7234, and 7235 and other RFCs that relate to how we have to transmit the data or communicate with the server (etc. etc. etc.). We primarily handle HTTP, we don't handle arbitrary URLs. That's a job for a library that will handle arbitrary URLs. (Hint: this was the point of urllib/urllib2)

Note, while people use requests for `unix://` or `file://`, we do not explicitly support these protocols purposefully. Our scope is very narrowly defined to 98% of our users concerns: HTTP. Those protocols are currently used through transport adapters and the adapters that provide this functionality are packaged separately.

If copying and pasting this code around is becoming a problem for projects (like httpie, docker-py, or whomever else) the solution is not to upstream the code here to be maintained by @Lukasa and me. The solution is to find people who care about maintaining it and make it its own library. If you think this code is too small for a library on its own, consider the fact that many of the auth libraries (kerberos, ntlm, etc.) are all similar in size to this code and are all packaged separately.

**tl;dr** We have no interest in making this a feature of the project or maintaining this code when the maintainers will not use it actively enough to be comfortable maintaining it.


@sigmavirus24: Thanks for the detailed explanation!