Redid CaseInsensitiveDict to work correctly/sanely

Fixes #649, ~~#1321,~~ and #1329. Don't merge yet, I want to get
some opinions about this implementation.

There are a few things I'd like input on. I completely rewrote `CaseInsensitiveDict` because it was hard to read. Instead of subclassing `dict`, this just implements the `collections.MutableMapping` interface, storing the data in an internal dict (._store). The result is far more obvious and readable.
1. The [old version](https://github.com/kennethreitz/requests/blob/40a060cf579a7f0996c92eed578148e526d9416f/requests/structures.py#L64-L66) returns None for nonexistent keys instead of raising KeyError. Do we actually need this behavior? My version doesn't do this, but it would be fairly trivial to add.
2. ~~Do we want header names to be titlecased? This stores keys and returns them in lowercase.~~

Please let me know if I can improve this at all.

EDIT: Doesn't fix 1321


Ok, so I redid this to directly subclass MutableMapping. The above concerns remain, and I'm also concerned that this will break session pickles. Do we care about breaking pickles?


Another concern, brought up by @gazpachoking: The original implementation preserves the case of the header name first inserted, this implementation does not.


> Do we care about breaking pickles?

Yes. Yes we do.


@sigmavirus24 So it doesn't break pickles. The loaded session pickle just uses the original's dict:

```
(.venv)cdunklau@krusty:~/Development/requests$ git checkout master
Switched to branch 'master'
(.venv)cdunklau@krusty:~/Development/requests$ python
Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Enabled tab completion
>>> import requests
>>> s = requests.Session()
>>> s.headers
{'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/1.2.0 CPython/2.7.3rc2 Linux/3.2.0-4-amd64'}
>>> s.headers.update({'Accept': 'application/json'})
>>> import pickle
>>> with open('/tmp/sessionpickle', 'w') as f:
...      pickle.dump(s, f)
... 
>>>  
(.venv)cdunklau@krusty:~/Development/requests$ git checkout case_insensitive_headers 
Switched to branch 'case_insensitive_headers'
Your branch is ahead of 'origin/case_insensitive_headers' by 1 commit.
(.venv)cdunklau@krusty:~/Development/requests$ python
Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Enabled tab completion
>>> import requests, pickle
>>> with open('/tmp/sessionpickle') as f:
...     s = pickle.load(f)
... 
>>> s
<requests.sessions.Session object at 0xf293d0>
>>> s.headers
{'Accept-Encoding': 'gzip, deflate, compress', 'Accept': 'application/json', 'User-Agent': 'python-requests/1.2.0 CPython/2.7.3rc2 Linux/3.2.0-4-amd64'}
>>> news = requests.Session()
>>> news.headers
CaseInsensitiveDict({'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/1.2.0 CPython/2.7.3rc2 Linux/3.2.0-4-amd64'})
```


Awesome, thanks!


Ok, so as of 2b92e2c, here are the changes from the original implementation:
1. CaseInsensitiveDict is rewritten as a subclass of `collections.MutableMapping`.
2. It remembers the case of the last-set key, but `__setitem__` and `__delitem__` will handle keys without respect to case.
3. It returns the key case as remembered for the `keys`, `items`, and `__iter__` methods.
4. Query operations (`__getitem__` and `__contains__`) are done in a case-insensitive manner.
5. The constructor as well as `update` and `__eq__` have undefined behavior when given multiple keys that have the same `lower()`.

Edit:
1. The `__repr__` now makes it obvious that it's not a normal dict.


_undefined behavior when given multiple keys that have the same `lower()`_ ? What happened to the `ValueError` idea? :)


@piotr-dobrogost There was some back and forth on IRC about it, and I was swayed. The undefined behavior is preferred because:
1. Simplicity. (KISS)
2. More dict-like in some circumstances.

But I can't remember the finer details. @gazpachoking, @Lukasa can you chime in?


@piotr-dobrogost Regular dicts have undefined behavior when you define two keys that are the same, since they are unordered `{'a': 3, 'a': 4}`, this would be the same as `CaseInsensitiveDict{{'A': 3, 'a': 4})`


Heh, coming from C++ (I guess the concept is present in other compiled languages, too) I take undefined behavior to mean the behavior is really undefined not that it's just not well defined which is what you describe and it's something quite different :)


Yeah, I was under the impression that doing what @gazpachoking described would cause a `ValueError`, but (totally insanely IMHO) it doesn't. So we should just match that behaviour.


Well, checking input arguments is not without cost and maybe this cost was unacceptable to authors of the standard dict (read Raymond :))?


> Heh, coming from C++ (I guess the concept is present in other compiled languages, too) I take undefined behavior to mean the behavior is really undefined not that it's just not well defined which is what you describe and it's something quite different :)

Oops, maybe I started using the wrong terminology and confused things.


Ok, looks like consensus on the "undefined" behavior for same-lower()-ed keys.

The only remaining thing: What should be the behavior of `__getitem__` for nonexistent keys? The original CID implementation returns `None` instead of raising `KeyError`.


I'm not sure the reason for the old behavior, but I vote for `KeyError`


Agreed. Let's be like `dict` wherever possible.


Sounds good. I need to work on the tests a bit more, then it'll be good to merge. Should I squash the commits and/or submit a new PR? This has gotten quite messy :)


The original claim that this fixes #1321 is incorrect. I have a test for it in 424c252, but it fails, so i've commented it for now.


Squashed changes into a new branch, PR #1339. Nitpicking, I know, but it makes it cleaner.