add cchardet support and use chardet as fallback

I created this pull-request for #4112 

sure :-)
I have to update the test settings as well to ensure chardet and cchardet run both

This whole thing scares me. 

I for one am not wedded to doing it: I'm nervous about the amount of code it adds as well.

@2mf do you have any metrics on how much faster cchardet is than chardet? e.g. is it worth the trouble?

@kennethreitz a benchmark can be seen at https://pypi.python.org/pypi/cchardet

> Python 2.7.12
> 	Request (call/s)
> chardet	         0.26
> cchardet	1341.81
>
> Python 3.6.0
> 	Request (call/s)
> chardet	        0.26
> cchardet	1472.43


@kennethreitz @Lukasa 
If you both don't like the idea of including cchardet. I don't have a problem with that but then there must be a possibility to use cchardet by monkey patching but this is prevented by other things like:

shouldn't be the version matching in the requirements of setup.py?
```
# Check chardet for compatibility.
import chardet
major, minor, patch = chardet.__version__.split('.')[:3]
major, minor, patch = int(major), int(minor), int(patch)
# chardet >= 3.0.2, < 3.1.0
try:
    assert major == 3
    assert minor < 1
    assert patch >= 2
except AssertionError:
    raise RuntimeError('Requests dependency \'chardet\' must be version >= 3.0.2, < 3.1.0!')
```
and
```
for package in ('urllib3', 'idna', 'chardet'):
    locals()[package] = __import__(package)
    # This traversal is apparently necessary such that the identities are
    # preserved (requests.packages.urllib3.* is urllib3.*)
    for mod in list(sys.modules):
        if mod == package or mod.startswith(package + '.'):
            sys.modules['requests.packages.' + mod] = sys.modules[mod]
```

That is significantly faster! 

> shouldn't be the version matching in the requirements of setup.py?

No, @2mf it shouldn't. Requests needs *very* specific versions of dependencies. Some of those dependencies are popular and we need a way to tell the user "You're using a version that will horribly break your version of Requests"

> That is significantly faster!

And harder to install and the benchmark, as I understand it, is based off a *very* old version of chardet and hasn't been updated since.

It sounds like we're against this change overall. Sorry @2mf. 

I'm on board with doing this, but the current methodology isn't 100% correct and I'm merely pointing out that those benchmarks are older and potentially misleading. @dan-blanchard has done a lot of fantastic work on chardet recently

I feel the need to point out that chardet is in the midst of gaining support for more codecs and languages than cchardet supports. I'm retraining all the models for greater accuracy too. Speed isn't everything with encoding detection.

Just for the sake of a recent benchmark
I did the same benchmark for chardet and cchardet that where done by @PyYoshi (on my machine) and the difference is still in the same dimension.

> Python 3.6.1
> chardet 3.0.3
> cchardet 2.1.0

> python test_chardet.py 
> chardet: 0.24908731023612882 call(s)/s
> 
> python test_cchardet.py 
> chardet: 1161.9214360906421 call(s)/s
> 

anyway, It is not worth to continue on this one while running against so many walls

I hadn't actually looked at the benchmark code cChardet uses before, but it just [runs the same small SJIS text file through both modules 100 times](https://github.com/PyYoshi/cChardet/blob/master/src/tests/bench.py#L9). I know cChardet will pretty much always be faster than chardet—in fact, if you look at old chardet issues, you'll even see that I once toyed with the idea of trying to merge the projects—but that is not an accurate benchmark, especially for something like requests where a good amount of the time is spent downloading the page content anyway. A requests-based benchmark would make sense for deciding if it makes a difference here.