Use a JSON-specific encoding detection when no encoding has been specified

Here's a proposed fix for issue #765.

When requesting JSON data for a response with no encoding specified, detect the encoding from `self.content` using a custom UTF encoding detector that uses knowledge about JSON to make an educated guess as to the encoding used.

If no encoding could be determined, decoding fails, or the JSON decoding fails, fall back to `self.text` and `chardet` guessing.

Tests included, tested on python 2.6, 2.7, 3.1, 3.2, 3.3. All code PEP-8 and pyflakes clean.


To clarify: if the body is RFC-compliant JSON, determining the UTF encoding is fully deterministic, no guessing required.

If the body is _not_ RFC compliant, then this method is no worse than the current 'guess-the-characterset' method used. If we cannot find evidence of any of the UTF encodings (no BOM, wrong null count, or the nulls in the wrong places) then it falls back to the old method. If we do decide upon a UTF encoding and the decoding _fails_, then we _also_ fall back to the old method.

Since UTF-8 is pretty much a fail-safe decoding option (thanks to the strict limits built into the multi-byte codepoint system), and the chances that you find a UTF BOM _or_ nulls in the same places for any other non-UTF encoding imaginable, the determination should not interfere with any edge cases that somehow manage to work today.

Such edge cases only include JSON encoded in a non-RFC compliant encoding, where that encoding is not specified in the Content-Type header. The encoding used should then fool the UTF detection, the actual UTF decoding, _and_ the JSON decoding before resulting in a change of behaviour. I cannot imagine what such data would look like, nor how `chardet` would do a better job in that case.


Perfect timing, I added a UTF-8 only implementation of this a few days ago in the "adapters" branch.


Hmm, my approach was to simply add this logic into the `get_encoding_from_headers` function. 

Ugly commit, but here was the basic idea: https://github.com/kennethreitz/requests/commit/2e7af6d6156125153855675268c3cf8cee7ab447#L2R364

I think it would be better to move your detection logic to that function and have requests use the normal "encoding" logic. 

Thoughts?


My reasoning for putting this in the `.json` property: clearly the caller is expecting the body to be JSON, so whatever the content type might have been, perhaps we should be a little more lenient and flexible.

So, I prefer the test to be made when the `.json` property is used, just like the encoding is only guessed when the `.text` property is being used.


Someone else found the `charset` issue on JSON ambiguous enough to [ask a Stack Overflow question](http://stackoverflow.com/q/13096259/100297) to ask for clarification. Defaulting to `UTF-8` looks more and more like an incorrect assumption.


I was wondering why I hadn't run into this with github3.py and then I realized that in my request headers I specify UTF-8 only and GitHub honors that. I suppose if I hadn't, I and others already would have run into this.


I'd much rather see this happen based purely on the headers, but I'll merge this since it requires access to the body to work :)